Show nearby share as a normal app target instead of action button. And
always put it as the first item in App prediction Row. The change is
gaurded by lowRamDevice flag and experiment flag. by default, there is
no change to current behavior. One needs to run command 'adb shell
device_config put systemui is_nearby_share_first_target_in_ranked_app true' on
Android Go devices to see the effect.
Bug: 197241083
Test: atest ResolverListControllerTest
Test: atest AbstractResolverComparatorTest
Test: atest ResolverActivityTest
Test: atest ChooserActivityTest (no new failure)
Change-Id: I22106e382e0d96fc760e4a9fb94be3ae293c8497
This combines two nearly duplicate sets of tests into a single reusable
base test class and adds test coverage for ListViewCaptureHelper and
WebViewCaptureHelperTest.
The tests cover scrolling, bounds checking and clipping and ensure
the captured region is centered vertically within the visible bounds.
Bug: 195109744
Test: atest ListViewCaptureHelperTest RecyclerViewCaptureHelperTest \
ScrollViewCaptureHelperTest WebViewCaptureHelperTest
Change-Id: Ia533d38238d2a0e0f44358d2033394ad1d70487f
The issue could be reproduced when the device defined an
overlay configuration file and an overlay package which
was in the configuration file also declared the required
system property in its manifest. The device works fine when
the required system property matches the corresponding
value on the device. But an IllegalStateException was thrown
from the system if it didn't match.
The root cause is that the package parser fails to parse the
overlay package if the required system property in the manifest
does not match the corresponding value on the device. It resulted
in the OverlayConfigParser could not find the package present
in the partition and throws the exception.
To resolve this issue, this CL skips the overlay configuration
if the package not found was caused by the system property
conditionon on the device.
Bug: 193422327
Test: atest OverlayConfigTest
Change-Id: I5650d796d92e3c4825b0d035e8e3b18f36d4cb47
This is a follow up CL to our previous CL [1], which introduced
early-exit paths to some RemoteInputConnection methods to protect
innocent IME clients from unexpected process crashes when an IME is
calling InputConnection APIs with invalid parameters.
Although protecting IME clients from crashes still makes much sense,
implementing it as an early-exit style in RemoteInputConnection may
expose observable inconsistency to IME developers in terms of the fact
that InputConnection#getText{Before,After}Cursor() can also work as a
fence operation that would not return until all the previously issued
InputConnection API invocations are handled in the IME client side.
With this CL, the following methods start behaving as a fence
operation even when an invalid parameter is passed, by checking the
parameters in the IME client side.
* RemoteInputConnection#getTextAfterCursor()
* RemoteInputConnection#getTextBeforeCursor()
* RemoteInputConnection#getSurroundingText()
There should be no performance impact for IMEs that do not make such
an invalid (and unnecessary) API calls.
[1]: I95169735198f8363c981a61e20234dfebfd645b1
1e72ef2893
Bug: 169114026
Fix: 194110780
Test: atest CtsInputMethodTestCases:InputConnectionEndToEndTest
Change-Id: Ie0c18d0c9b8bf8f02f2fcdca5aac7e580c6bf2cd
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
