This CL fixes an edge case that my previous CL [1] forgot to handle.
The goal of my previous CL was to avoid InputMethodManager from getting
confused by a false focus-in event from temporarily detached Views.
However, my CL forgot to take care of the case where the temporarily
detached View is still focused even after the temporary detach mode is
done.
The bad news is that such a situation is relatively easy to trigger by
having a ListView that has EditText as follows, which seems to be
known to be a common technique in Android developer community to put an
EditText in a ListView.
ListView#listView.addHeaderView(new EditText(context), null, true);
If the ListView is initialized as above, and the EditText has input
focus, View focus and IME focus start to disagree immediatelly after the
ListView's layout is re-evaluated. This is really easy to trigger, for
example just by dismissing the IME window.
In summary, the root cause is that InputMethodManager#focusIn(View) is
now always ignored as long as the View is temporarily detached, under an
assumption that IMM#focusIn(View) will be called back again with a View
that is not temporarily detached when everything is stable. Hence the
fix is to do so by hooking up View#dispatchFinishTemporaryDetach() to
call IMM#focusIn(View) again when the View is actually focused in the
final state.
[1]: Ia79bbd8468f768d546354382b47b39dd31ef7bb5
a4ed0cfcb6
Bug: 30022872
Bug: 30578745
Bug: 30706985
Change-Id: Iecbdb00dcef8c72e4f7b31035c9bf0f4a40a578f
(cherry picked from commit dd228fbb4d)
View attachment calls jumpDrawablesToCurrentState(), so the view state
needs to be set up prior to attachment. For views that are already
attached but are being moved to a new position, manually jump.
Cleans up comments in methods that were modified.
Bug: 29978498
Change-Id: Ica27b2c60ad7ee98b9d1e4912c4f8b8c248af88d
(cherry picked from commit 26489e1688)
Instead of crashing, log a wtf and recover. This is not a problem
in ArraySet, but caused by someone else using an ArraySet without
protecting access to it. So whoever is calling at this point is
not the cause, and it isn't worthwhile to let them crash.
Change-Id: Iaefa4315b620c9fe24b31507e4aa47a8525c8540
(cherry picked from commit 92aa4b2ba3)
Changing the service side to accept descriptions of
motion events, not motion events themselves, so we can
control their creation.
Bug: 30647115
Change-Id: Ia6772a1fc05df91818e3f88959d1e2b4a35fe0cc
(cherry picked from commit a8918f23c7)
Don't write partial requests, and don't return (or throw) early after
partially reading a response.
bug: 30143607
Change-Id: I5881fdd5e81023cd21fb4d23a471a5031987a1f1
In the class description, fixed the reference link that points to the
Fragments guide.
Bug: 29007808
Change-Id: I3399e5f10c461eb6666a04f8829c6cde774948e0
If we enter multi-window mode or load WebView
assets into a Resources object, then the underlying
AssetManager instance may change.
crbug.com/627586
Bug:30118654
Change-Id: I837637bdad5370809db7f060d7d8536b536cad9e
Added a bit more information in the javadocs about the new constant
ENCRYPTION_STATUS_ACTIVE_PER_USER in related methods/constants so
that developers don't miss checking for that constant when targeting
API Level 24.
Change-Id: Id9cd6248637fe0fc28d5161344abe02614b5f502
Fixes: 30073719
Document that getClipDescription() and getLocaState() do not return valid data
when getAction() == DragEvent.ACTION_DRAG_ENDED.
Bug: 30016099
Change-Id: Id98fe8c5d6f052fc51c8c9e8d55329e162bd96b1
We use 'this' for synchronization in NameValueCache but some code
that accesses the generation registry uses 'this' in a different
context ending up syncing on the wrong instance. This is why
sync on this is just a bad idea.
bug:29956424
Change-Id: Ide2d4f07a5f40cb3f0e8f50e4c8de216d15a31ee
append() is used to optimized insertions in the array, but it must
preserve the order of the hashcode array; when it doesn't, it falls back
to append(), but it should not log a warning message
In particular, PendingIntentRecords might have different hashcodes
across different processes.
Fixes: 29912192
Change-Id: I0ab566249829ddb934fd51cf21399b68cb286bd5
Fixes a case where notification header text could go missing
if a notification view was recycled and previously had a header text.
Reapplying only hid the text without clearing it, so the extraction
logic thought it was still there and hid the text for the children
even though it was not showing for the parent.
Change-Id: I3f96e1e7bebb2f815020d278ad13b2b5d948e63c
Fixes: 29915184
In extreme cases the list of recent tasks can grow beyond the size
of a single Binder transaction. This change moves over to
ParceledListSlice which handles chunking any large results.
Bug: 29635557
Change-Id: Iaf1227234f5f8c9451f73a6a5c1dc89f2067f05f
Since all pending intents are stored on a Set in the Notication object,
there is no need to individually check for specific pending intents.
BUG: 29480440
Change-Id: I27a18bb535a9a4bb6cb4e76bdc189e6c315a684a
Exception when targetSdkVersion is a letter API [eg 'N']. While this
is technically not according to the external docs, it's the behaviour
with prior platforms.
Bug: 29817839
Change-Id: I8382909dbe62de7b2ddfb7995ce11d5c2f43372e
We need to make every peniding intent that went in the notification
system to allow special handling of such intents when fired by a
notification listener. If a pending intent from a notification
is sent from a notification listener, we white-list the source app
to run in data saver mode for a short period of time. The problem is
that actions and the notificaion can have extras which bundles may
contain pending intents but the system cannot look into the bundles
as they may contain custom parcelable objects. To address this we
keep a list of all pending intents in the notification allowing
the system to access them without touching the bundle. Currently
the pending intents are written to the parcel twice, once in the
bundle and once as the explicit list. We can come up with a scheme
to optimize this but since pending itents are just a binder pointer
it is not worth the excecise.
bug:29480440
Change-Id: I7328a47017ca226117adf7054900836619f5679b
