Internally, DownloadManager synchronizes its contents with MediaStore,
which relies heavily on using file extensions to determine MIME types.
To prevent these two databases from getting confused, this change
adjusts DownloadManager to force the MIME type of already-completed
downloads based on the file extension, matching what MediaStore does.
Bug: 159594536
Test: atest PublicApiAccessTest#testAddCompletedWithoutExtension
Change-Id: I60c613eafcfe55007dffcac2d7d1fe375b753c19
This restores the logic removed from SelectionModifierCursorController
in ag/9994946. A quick sequence of "tap", "drag", "tap" events (such
as when quickly scrolling a small input field) should *not* be treated
as a double-tap.
Bug: 158948887
Test: Manual and unit tests
atest FrameworksCoreTests:EditorTouchStateTest
atest FrameworksCoreTests:EditorCursorDragTest
Change-Id: I9fb9cb06b1e208946566a0f70697c62ee7684ca0
* The problem with sending empty response to IME is that the IME
may want to handle the following two cases differently:
a) all suggestions are filtered out due to user typing: ime may
want to immediately delete the existing suggestions to make
place for other types of things, such as IME's own word
completion or next word prediction.
b) the current input connection is finished and a new connection
will be created with the same field or a different field:
ime may want to delay removing the suggestions so that if there
is new inline suggestions coming soon after for the next
connection, the UI transition can be smoothed out by skipping
the gap of deleting the old suggestions and showing the new
suggestions.
* We used to rely on the IME impl to clear the suggestions when input
is finished. That was done to give the IME the flexibility to
smooth out the UI updates. Otherwise in case the input connection
is finished and immediately started again on the same field,
and there is another non-empty suggestion coming after short after,
it would cause UI flicker. Because the suggsetion chips would
disappear for a short moment and then appear again.
* The previously implemented solution was to have the IME impl post a
delayed deletion of the suggestions when onFinishInput is called.
* In this patch, we get around this issue by synchronously clearing
the inline suggestions right before the onFinishInput. Then the
IME impl can post a callback to the main thread to do the actual
delection. And in the callback it can check whether onFinishInput
and onStartInput was called right before to determine whether
it needs to delay the delection or delete immediately.
* Also done in this patch is to clear existing inline suggestions,
if any, before IME creating a new callback connection to the
framework.
Test: atest android.autofillservice.cts.inline
Bug: 157515522
Change-Id: I6fd5d294cf8676a24b8576ea554824608672ce49
* Add hashCode() to the base Violation class for dup detections
* Discard obsoleted violation fingerprints if possible
Bug: 159128771
Bug: 159626227
Test: run cts -m CtsOsTestCases -t android.os.cts.StrictModeTest
Test: Manual - Loop generation of StrictMode violations
Test: Manual - Check heap dump
Change-Id: I19a0922fe010fad97b6b819e73acb7db08f84930
Activity was still referred from ImeInsetsSourceConsumer after
ViewRootImpl's mView was destroyed when ViewRoot's surface is cleared
using die signal.
This CL makes sure we still free-up resources at die signal.
Fix: 157955883
Test: atest NexusLauncherTests
Change-Id: Ia48f7b7a8cf6b867ce75b2b7393a60ba73b0c3d0
During transitions and while the IME is controlled by the app,
the IME may be "visible" as far as the IME framework is concerned,
but not actually perceptible by the user due to offsets or alpha
applied to the leash.
This may lead to out-of-place navbar symbols for the IME, especially
in gesture nav.
To avoid this, the ImeInsetsSourceConsumer now notifies the IMF of
whether it has made the IME unperceptible to the user.
For now, we ignore the cases where the IME is controlled by something
other than the client window - in that case, we just revert to the
previous behavior of it being always considered perceptible.
Fixes: 158079255
Test: manual, launch email compose activity, observe that back button only indicates once IME appears
Test: atest InsetsAnimationControlImplTest
Change-Id: I4dc9d6513d0559156f7da39244f3fc5ebc952ed4
CL[1] introduces new WINDOW_FOCUS_GAIN_REPORT_ONLY flows to notify
InputMethodService only reports IME input target to WM when focusing to
the next window and its input connection remains.
Originally in android Q and prior devices, we don't need such report
mechnism but just skip to start new input connection and ignore
onStartInput / onFinishInput for the above use case.
Since starts from Android R, new IME insets control APIs relying on this
mechanism (see CL[2]) to keep the actual IME input target up-to-date.
As we expected there should be no new input connection and additional
onFinishInput when CL[1] landed.
However, in IMMS, startInputUncheckedLocked will be called
to callback additional onStartInput for InputMethodService, which mostly
is not expected, except when focusing the same window after device
turned screen on, we need to start input and callback onStartInput to
align with the behavior of android Q or the prior platform.
Besides, to have more clear code logic and debugging concept of
ignoring onStartInput and onFinishInput only when focused the same editor
with input connection remains, we remove WINDOW_FOCUS_GAIN_REPORT_ONLY
reason and introduced 2 more start input reasons to distinguish the
different behavior:
- WINDOW_FOCUS_GAIN_REPORT_WITH_SAME_EDITOR
- WINDOW_FOCUS_GAIN_REPORT_WITHOUT_EDITOR
[1]: I45a9814d812ad906f417c24200fd4219959e2423
[2]: I9e8984b7e5aa989a53ece9e2576393f795b9ef94
Fix: 158624922
Test: atest FocusHandlingTest InputMethodStartInputLifecycleTest
Test: manual as below steps:
1. Use Gboard, Open the emoji keyboard
2. Swipe down to reveal notification shade
3. Swipe up to dismiss notifications
4. Expect the Emoji keyboard is still open without close
Change-Id: I2da99ae67b9ce4051dec0c0f0e975ebe6e1ab118
This reverts commit 6d834d86fb.
Reason for revert: <http://b/159230864 WhatsApp image is visible after existing a chat>
Bug: 159230864
Change-Id: Ib266cff2e06a82ae9a0e85142ef80ae00328a040
When IME has zero insets, it doesn't map to any side and doesn't have
can't be animated.
IME can have zero insets in following cases:
1. Floating IME
2. Fullscreen IME (in landscape)
3. IME doesn't overlap with IME target window.
In order to animate a type, it must have insets. We can animate IME
from negative insets to zero and vice-versa. This makes zero insets IME a
special case of ISIDE_BOTTOM.
Deprecate SIDE_FLOATING because it shouldn't logically map to a side.
Fix: 153909316
Test: atest WindowInsetsAnimationImeTests#testZeroInsetsImeAnimates
Change-Id: I6d1d3430888db4632cb2f93e9042f692b35ebaeb
In Android 10 additional restrictions were required to access the
subscriberId. The NetworkStatsManager has several methods that accept
a subscriberId of the mobile network for which usage should be queried.
This commit updates the docs for these methods to reference the new
access restrictions and offer null as an option to obtain the usage
for all mobile networks.
Fixes: 157871064
Test: m docs
Change-Id: I95c730c9418fced6312eb3ba4e0d69e6299f3ded
