Use the passed-in user instead of the current user to determine
whether or not to add the work profile badge to direct share
target app icons, so that personal share targets do not have the
badge (even when sharing something from the work profile) and
work/managed share targets do have it (even when sharing something
from the personal profile).
Test: manual; tested appearance sharing from personal->work and
from work->personal
Bug: 197388251
Fix: 197388251
Change-Id: Ieee50d46e8058a92efa5be8aae9859447531c270
Per b/132321687, we need to leave the system-side share
activity open (not call finish()) until the SysUI-side
chooser finishes, or else we'll invalidate the start-
activity token that the SysUI (delegate) chooser needs
when it launches the target activity.
Note that the delegated flow is still disabled by the
flag in DisplayResolveInfo.
Bug: 132321687,199743918
Test: Reproduced crash condition & confirmed fix manually.
Change-Id: Ic467dfe4eb417ca846c0ecf2e8a0067bd5275e9f
This CL effectively replaces my previous CL [1], which made
unimplemented methods in InputConnection not fatal errors, with a
simplified implementation that still gracefully take care of
unimplemented methods without causing app crashes.
Instead of propagating missing method information from the IME client
to the IME process, this CL will simply catch AbstractMethodError in
the IME client process. Doing so enables us to
1. preserve the strict invocation order of InputConnection APIs, and
2. achieve the same goal with fewer lines of code.
The additional cost of throwing (and catching) AbstractMethodError
every time the IME calls an unimplemented InputConnection API can be
justified as it is really an exceptional scenario, and avoiding it
would require extra maintenance cost as seen in
InputConnectionInspector.
The above overhead (and complexity) due to AbstractMethodError can be
avoided by adding default implementations to those InputConnection
APIs, but doing so requires API signature update hence API council
approval to go ahead, which is to be discussed in Bug 199934664.
[1]: I3c58fadd924fad72cb984f0c23d3099fd0295c64
19a80a1e80
Bug: 27407234
Bug: 27642734
Bug: 27650039
Bug: 194110780
Test: atest CtsInputMethodTestCases
Change-Id: I9e801e92496a6e16cee37664870c97ed096f1413
Today's flow of events is like this: key goes to focused app
(ViewRootImpl::processKeyEvent), the view hierarchy does not handle the
event, so ViewRootImpl uses FallbackEventHandler to invoke the fallback
action for this key.
The problem is that for many keys the app itself is closing system
dialogs before taking the appropriate action (often launching an
activity, eg. dialer for KEYCODE_CALL), but this is now prohibited in S
due to abuse of said action.
The long-term plan is to return to InputDispatcher the fact that the key
wasn't handled by the app and have ID call out to the policy, which will
launch the appropriate action and adjust the UI as it sees fit (close
system dialogs).
However, we need to prevent apps from crashing because of this, hence
this change for S still. The unfortunate effect is that system dialogs
won't be hidden in these cases, but this livable with until we properly
implement the infrastructure.
Bug: 199173862
Test: Simulate code-paths with affected keys and make sure apps don't
crash:
1. adb shell input keyevent --longpress KEYCODE_CALL
2. adb shell input keyevent --longpress KEYCODE_CAMERA
Change-Id: I44ad41ac1eac9acc8320298ceb4c1b21bde8af5d
This CL is a follow up CL to our previous CL [1], which introduced
InputConnection logging as part of IME tracing project.
The goal of this CL is to consolidate RemoteInputConnectionImpl by
separating core business logic from orthogonal concept such as method
tracing, without sacrificing the runtime performance.
With this CL, both code and string resource duplicates will be
actually reduced. There is no additional object allocation unless the
IME tracing is explicitly enabled.
[1]: Iabd6af1b858803030848a0ef5e7dd9ecfc562716
0653b692d1
Bug: 154348613
Bug: 192412909
Test: Manually verified that the IC tracing is still working
Change-Id: I329129241bdae231844dc3170faf9e8d11f49f08
This change removes the use of setWaitForPresent(true)
on the FrameRenderRequest. This allows the method to return
as soon as the request is synced to the RenderThread and
no longer block while the frame is drawn.
Depends on ag/15411889
Bug: 194927650
Test: manual, capture long screenshot
Change-Id: I93795f3aad52067e52d3614982fd871de4f3432e
This is a follow up CL to my previous CL [1], which used
MissingMethodFlags mechanism [2] to let that API fail when the IME and
the target app are not running on the same display.
As discussed in Bug 194110780, however, there is a problem in the
MissingMethodFlags mechanism that it could have caused unexpected task
reordarings from the IME developer when sync InputConnection APIs
immediatelly fail without waiting for those tasks to be scheduled to
the target app then handled.
As a preparation to fully deprecate MissingMethodFlags, this CL
enables InputMethodManagerService to stop lying about
MissingMethodFlags.REQUEST_CURSOR_UPDATES
when the IME is rendered on a diffirent display than the target app.
Such check is now explicitly implemented in
RemoteInputConnectionImpl.
Other than that, there is no observable behavior change.
[1]: Ie2f7a5117cff3a13ad5c5806fd4b3abef7569549
3d2cc0fffd
[2]: I3c58fadd924fad72cb984f0c23d3099fd0295c64
19a80a1e80
Bug: 131368625
Bug: 194110780
Test: atest CtsInputMethodTestCases
Test: atest MultiDisplaySystemDecorationTests#testCrossDisplayBasicImeOperations
Change-Id: Iec12733d37e112b7271436bba15094ae2a55a450
