Use span properties to detect:
* Composing text - don't record undo operations
* Completing a composition - record an insert undo operation
* Canceling a composition - don't record
Save the composition state on parcel/unparcel.
Stop using begin/end batch edit to try to detect when a TextWatcher
is modifying the text. IMEs trigger multiple InputFilter passes in
a single batch edit. Use SpannableStringBuilder to determine when
we're in a TextWatcher callback because it is the authority on that
state.
Fix a bug in undo manager where it doesn't forget undos correctly if
there are more than one in the stack.
Bug: 19332904
Change-Id: Iaa9b0b2a7bf6683302cc85e7616e5d5fcc9fa202
Previously, hardware rendering cannot be enabled or disabled
on windows created without a parent activity (e.g. by services)
by setting the <application> tag, "android:hardwareAccelerated"
in AndroidManifest.xml. It's enabled by default in Android L
from the commit, 5e1565ead6dbb7d5c414522591f61b16a23de1c3.
This patch provides a way of setting hardware rendering for
that case.
Change-Id: I60ee9566e99db39cd661fe6f196f43c3968b311a
Signed-off-by: Dohyun Lee <dohyun.lee@lge.com>
Previously, hardware rendering cannot be enabled or disabled
on windows created without a parent activity (e.g. by services)
by setting the <application> tag, "android:hardwareAccelerated"
in AndroidManifest.xml. It's enabled by default in Android L
from the commit, 5e1565ead6dbb7d5c414522591f61b16a23de1c3.
This patch provides a way of setting hardware rendering for
that case.
Change-Id: I08ce58a8644970a2a18407e83ad317a72a2dad10
Signed-off-by: Dohyun Lee <dohyun.lee@lge.com>
These fragments were left over from the edit process for the original
CL (http://ag/586972). The paragraph they belong to was removed.
See first comment for doc stage location.
bug: 19793140
Change-Id: Iafa30c4036c57ba00b534d619cd1fa4135f60175
This used to fire the "paste" popup instead. It is a tiny step towards
unifying the cut/copy/paste action mode and paste popup.
Change-Id: I03dfcc294d4453e92464fc4f714468f58c692f24
The attribute declares whether the app intends to use cleartext
network traffic (e.g., HTTP, WebSockets, XMPP, SMTP, IMAP -- without
TLS or STARTTLS). The default value is true. If set to false, the app
declares that it does not intend to use cleartext network traffic. In
this case the app requests the platform, tooling, and third-party
libraries to prevent it from using cleartext traffic. The danger of
cleartext network traffic is that its confidentiality, authenticity,
and integrity are not guaranteed.
This feature is designed to help apps which care about security of
data exchanged over the network. These apps can accidentally
regress/downgrade to using cleartext network communications. This
typically happens when the server the app communicates with all of a
sudden tells it to use cleartext communications (e.g, HTTP URL
instead of an HTTPS URL) or when one of the components of the app gets
updated and regresses to cleartext communications without the
developer noticing.
In general, the prevention measures are on best effort basis. It's
impossible to automatically prevent all instances of cleartext
traffic. For example, an app bent on bypassing restrictions could
perform low-level network I/O with unusual TCP packet fragmentation,
or could use a custom application-level protocol.
The expectation is that most apps use libraries for network
communications and these libraries over time will start to honor this
flag, thus increasing the protections offered by it.
Bug: 19215516
Change-Id: I8700d51ddbc5d528faa4b6a5fa5bc9551ad02d13
