Will come around in follow-up CL to fix & un-ignore.
Test: atest --test-mapping frameworks/base/core/java/com/android/internal/app
Change-Id: I99e98d3485c29722529f3619a624b5bd95126590
In the new flow, ChooserListAdapter didn't actually depend
on this data for anything (and ChooserActivity only ever
sent an empty list). In preparation for removing the
(internal) ChooserTargetServiceConnection class altogether,
this CL removes it from the ChooserListAdapter API: the
only reference outside of ChooserActivity.
Test: compiles.
Change-Id: I2c379562e47fba405714b08632118af2e16d8a40
This timeout was intended for the deprecated ChooserTargetService,
and as of ag/15644659 we no longer rely on it in the new flow.
Since we're no longer dependent on CTS connections for our
completion conditions, the timeout-handling logic was always fired
both on the "min" and the "max" watchdog periods, apparently
resulting in a spurious additional logDirectShareTargetReceived
call (both with ACTION_DIRECT_SHARE_TARGETS_LOADED_CHOOSER_SERVICE).
The new condition added in ag/15644659 results in an *additional*
spurious log event when the share targets are finished loading,
but as of this CL that load-completion callback will be the sole
place that we perform the logging.
Test: manual / presubmits
Change-Id: Ied1f7c90159d4db42669f0b7e046a9c0a16cb6d0
Prior to this change, we've implicitly relied on the async
Direct Share results coming in before the service watchdog
timer goes off. This has several issues -- the results may
not *actually* come in before the timeout; the old flow
still depended on us waiting for the full timeout even if
we were done sooner; and it's only somewhat inci dental
that we were even still scheduling the timer in the first
place, since that occurs on a code branch that's slated
for deletion. This CL makes those assumptions explicit in
preparation to remove the timeout logic altogether (and
then from there to remove the rest of the ChooserTargetService
support in ChooserActivity).
There are a couple concerns we should consider in review:
1. I don't know why the sendShareShortcutInfoList()
helper had been implemented to send RESULT_COMPLETED
only if it notifies at least one SHARE_TARGET_RESULT
event. It seems to me that this is an essential step
to gate the progress of our async flow, but (on a new
phone with no apps installed as share targets) I
ended up never seeing the COMPLETED event at all.
With the change from this CL, I see the COMPLETED event
exactly when I would expect -- but I could easily be
missing something about the original intention of
this code. (However I will note that there was no
logic to retry the request if resultMessageSent is
false, so it *seems* like we're just left hanging
in this case?)
2. In practice, this change allows the flow to complete
immediately once the Direct Share targets are received,
since we'll never have any service connections to
wait for. That's great -- it means we can get to the
completeServiceTargetLoading() event that signals the
end of our flow, effectively one full second earlier
(confirmed in informal testing). However, as currently
written, it's actually possible that we'll signal
completeServiceTargetLoading() more than once;
ChooserHandler's maybeStopServiceRequestTimer() method
is poorly-named and doesn't actually cancel the
timer, nor otherwise ensure that we haven't already
completed.
IMO this should be OK since it's already happening
without this change (we were already firing twice, for
the min & max watchdog timer events), and I expect to
clean it up in my next CL anyways. Just wanted to call
attention since this will result in one *additional*
"extra" event until the timer logic is removed.
Test: manual (may need more coverage)
Change-Id: I62c714b235fe5521b1ad01c3556a5a6be1db539c
If the lists of custom power components do not match, a crash will occur.
Instead of causing a crash, simply skip incompatible snapshots.
Bug: 196040329
Test: atest FrameworksCoreTests:com.android.internal.os.BatteryUsageStatsProviderTest
Change-Id: I87ba605371a5f3119dcff33f6109e94ee46ab57d
Fixes: 195019654
Test: post CallStyle notification without custom action; observe text
Test: post CallStyle notification with custom action; observe buttons shrink to icon only.
Test: repeat tests using various font and screen sizes.
Change-Id: Icbd6189a1e03494e481e8672263570ae2657f946
The icon loading inside the sharesheet happens as a separate
async task inside the bindViewHolder. We have seen it taking longer
time in some cases which caused the icon loading to happen after the
bindViewHolder resulting in empty icons being loaded in the
sharesheet for wembley/namaste phone devices. This change introduces a
call to notify observers after the icon loading is done.
Test: Tested on device
Bug: 194886990
Change-Id: Id1752f10ced7877efe5eff90aac6db2bd656f34c
Right now it crashes if we miss an up event since the active pointer
won't get reset. We can't just clear this in onDetachedFromWindow
because of how it gets drawn in system_server, so instead we just check
before using the active pointer.
Bug: 109779280
Test: put settings into split screen, frequently enable / disable
Pointer Location while tapping in another app window. See that it
doesn't crash.
Change-Id: If2b1f3157574c962b24115b0ecf0a27feec8e84c
PackageParser.PackageParserException is deparected, and should be
either using the PraseResult or throwing a more generic Exception.
Remove the unused setError method.
Besides, using alternative instead of PackageParser when checking
AndroidTestBaseUpdater.
Bug: 174723245
Test: build
Test: atest PackageBackwardCompatibilityTest
Test: atest AndroidTestRunnerSplitUpdaterTest
Change-Id: I572d167ae3d794ef9f11e7564f09694d0f906f0c
This is a follow up CL to our previous CLs [1][2], which introduced
an @hide callback
View#onInputConnectionClosedInternal()
to notify View when an is closed.
What this CL aims to do is to fix a potential problem in a code path
that has not been yet used. Thus there should be, in theory, no
observable app compat impact.
The problem is that
RemoteInputConnectionImpl#deactivate()
can dispatch
A: View#onInputConnectionClosedInternal()
before
B: InputConnection#closeConnection()
is completed when A and B need to be dispatched to two different
threads. This can, in theory, happen when
A: View#onInputConnectionClosedInternal()
C: InputConnection#getHandler()
are both explicitly overridden. That said, A is still @hide and only
by TextView, which basically does not support InputConnection with a
custom InputConnection#getHandler().
Anyway, with this CL A is guaranteed to happen after B under any
circumstances.
[1]: Iaafb0a03126c9292c24415f866dbdd72cadfa239
7b384751ea
[2]: I9280604e7ec7e8d08c1179e6bbf0068647a41040
7b384751ea
Bug: 163400105
Test: atest FrameworksCoreTests:ViewInputConnectionTest
Change-Id: I8a0e321ecf6e0b3be4b6ab1a35e6ac7259826c2e
This is a mechanical refactoring CL that locks down
RemoteInputConnectionImpl#getInputConnection()
as a private method.
This is supposed to be helpful to to avoid future misuse of raw
InputConnection instance outside RemoteInputConnectionImpl.
Note that InputMethodManager#isAcceptingText() remains to have the
same observable behavior in this CL. The key fact is that the
following two fields are updated in an atomic way.
* RemoteInputConnectionImpl#mInputConnection
* RemoteInputConnectionImpl#mFinished
Bug: 192412909
Test: presubmit
Change-Id: Ic5fbc6213ad62df95fc0b7eef18bab1fd9fbdbf1
This CL fixes a regression that
InputConnection#reportFullscreenMode()
is always called back on the main thread rather than its associated
thread. In most of cases those two threads are the same hence there
is no semantic problem, threads are the same, but for some special
cases, e.g. when apps explicitly override
InputConnection#getHandler(),
our thread affinity contract can be violated.
This regression was accidentally introduced in Android O time frame
while attempting to make the system more robust at Bug 28406127 [1].
Although we have never received any actual issue report from app
developers so far, this is still worth fixing.
[1]: If23e7c7c265ab3dfb48c2fb6fdb361b17d22c594
2bc66171cc
Bug: 28406127
Fix: 193588937
Test: atest CtsInputMethodTestCases:InputConnectionHandlerTest
Change-Id: Id3ac21c11d6b062bb66719109376ff642309b8ff
This is a mechanical refactoring CL that renames
com.android.internal.view.IInputConnectionWrapper
to
com.android.internal.inputmethod.RemoteInputConnectionImpl
with no observable behavior change.
Bug: 192412909
Test: presubmit
Test: No lint error under core/java/com/android/internal/inputmethod
Change-Id: I171106ad0b46fbb495a6bf08d10f33915c2d29ac
This is a clean-up CL for up my CL [1], which introduced
InputConnection#getHandler()
per request from the Chromium team.
This CL only renames misleading and/or inaccurate code commends and
field names. There should be no observable behavior change.
Even before my change [1], IInputConnectionWrapper had been
responsible for re-dispatching incoming IPCs onto the "UI thread"
obtained from View#getHandler(), which is not guaranteed to be the
"main thread" in some rare situations.
With my change [1], the target thread is no longer limited to the UI
thread.
This CL removes misleading and confusing "main" terminology from the
variable names and comments for future readers.
[1]: Id9e579bb3e2966986cdcb1c34bc8cacfeca2e1a9
612cce92ad
Bug: 26945674
Bug: 192412909
Test: presubmit
Change-Id: Ibb31da4f66e8a6cd35f93c3ca1cc0f871dfb3b73
Fixes: 195019654
Test: post CallStyle notification without custom action; observe text
Test: post CallStyle notification with custom action; observe buttons shrink to icon only.
Test: repeat tests using various font and screen sizes.
Change-Id: Icbd6189a1e03494e481e8672263570ae2657f946
