Notification children were not properly handled
before when added lead to a crash.
This will fix this bug finally.
Bug: 21868047
Change-Id: I92f2f7e71659de8274711a448e370084d423ca9f
In TextView's onPreDraw method, startSelectionActionMode()
is called, but the selection has already been started so
in startSelectionActionMode() it shows the
insertionController which hides the selectionController.
Fix this by adding a check to start the action mode only
if it is not already started.
Bug: 22028858
Change-Id: I2999423155b7a63a7d879bc8ea5032e17dff459f
Custom parser can handle nested ICU messages even if they
are split into multiple fragments. Code reworked to encapsulate
all pseudolocalization logic in Pseudolocalizer and PseudoMethods
classes. To minimize a changelist size, some static functions
remained. Fake BiDi pseudolocalization method is reimplemented
to handle word boundaries correctly. Unit tests added.
(cherry picked from commit cbb1e676b56677ae3585c067f29646dddffb4857)
bug: 22060509
Change-Id: I11968d81984d99501a4d9334ff2e7453a1eb7a00
This reverts commit c83d3e4b72f8f25bbac39a577f125f0ca04354da.
While the above patch does help deal with the issue of "lost" kernel
alarms, experiments found it to also cause the unnecessary duplicate
setting of non-lost alarms in other devices.
This leads to a situation where the CPU constantly tries to sleep, but
occasionally keeps failing to do so, because of a collection of these
duplicate alarms constantly activating the "alarm" kernel wakeup source
, presumably due to them being triggered.
These might have accumulated over several iterations when the kernel
alarms were set again (via rescheduleKernelAlarmsLocked()).
To prevent the CPU thrashing (which heavily drains power on more
battery-constrained devices, and increases the number of alarms being
set), the aforementioned commit is backed out.
Change-Id: I2a189cb303deb78a2faf476b0e789445407f3e11
(cherry picked from commit d19ffd4f2ca4130c41dd5f6baddad1830598ecbc)
Cherry-pick from master
This change adds four new stem keycodes for Android Wear. These
keycodes are intended to represent the various hardware buttons
around the watch. There is one primary stem key that will be used
for power/settings and three generic stem keys that will be
customizable.
BUG: 21903503
Change-Id: I867cf79554c72d42c8acbb3ff8b1678e482d4fe2
Permission checks are enforced within the SettingsProvider specifically
for SECURE/SYSTEM/GLOBAL. Now WRITE_SETTINGS is runtime, so it shouldn't
apply to all the settings types.
Bug: 22044704
Change-Id: I9ed25d96b2fa4f46d3d049efa4300cd1d37bbd24
Keymaster's implementation of ECDSA with digest NONE rejects input
longer than group size in bytes. RI's NONEwithECDSA accepts inputs
of arbitrary length by truncating them to the above size. This CL
makes Android Keystore's NONEwithECDSA do the truncation to keep
the JCA and Keymaster happy.
The change is inside AndroidKeyStoreECDSASignatureSpi$NONE. All other
small modifications are for supporting that change by making it
possible for AndroidKeyStoreSignatureSpiBase to pass in the signature
being verified into KeyStoreCryptoOperationStreamer. This in turn is
needed to make it possible for NONEwithECDSA implementation to provide
a wrapper streamer which truncates input.
Bug: 22030217
Change-Id: I26064f6df37ef8c631d70a36a356aa0b76a9ad29
Also clears DrawableContainer's futures list when it's no longer needed,
correctly sets deep copy of state set in StateListDrawable, makes some
private methods into package-protected to avoid thunk, and propagates
state to StateListDrawable's super class so that getState() has correct
information.
Bug: 21840003
Change-Id: I0d4232807f280d663c03b4a80e4aab8626806440
The measureText method when applied to a string should just measure
the substring, rather than treat the entire string as context. It was
less likely to cause problems than the similar issues with char
arrays, but still wrong. This patch makes the behavior consistent.
Bug: 20087437
Change-Id: I1c6e07a694b151f4fb097edae8e271805e996d06
Only prune ChooserTargets if the resolved activity source they came
from is still present after refreshing the list. Compare this directly
against the ComponentName rather than ResolveInfo.equals, as the
latter isn't implemented.
Bug 21953672
Change-Id: I6486bda85c19d7371167affe2a2b80a2668bd734
