This reverts commit ebe9c0dbebbd8c2a23a76ff827b90e66ce3813bf [1],
because it caused a regression that IME window becomes transparent on
the lock screen (Bug 28013209).
[1]: I7d406cc88aae40a8b22c1fc1d856ccb7b6bb4558
Bug: 26387930
Bug: 28013209
Change-Id: I11243703030e34b917136b69a35245e9ef73c87c
The proxy MidiReceiver in the USB device was not forwarding the flush
command to the event scheduler.
Bug: 25511696
Change-Id: I6a4759b71bc8f9ae3e20aed1238f62a2ed405e24
Signed-off-by: Phil Burk <philburk@google.com>
Also cleaned up the methods names a bit and fixed some small
bugs in border cases where the algorithm was using the wrong
sizes.
Bug: 24866646
Change-Id: I6622814f8cec3fe143234e349030a19e3dc11353
fontchain_lint scans directories in $(TARGET_OUT). There is no better
target working as dependency than the system.img.
Change-Id: I560b89f697e5ebd4f1e44a150f5af37996cf427e
Seems that there are two mutually exclusive requests about how IME
switcher visibility should be controlled.
A. Requests like Bug 19496012. We should show the IME switcher
as a quick access to "Show input method" setting when a physical
keyboard is attached via wireless connections that do not have
clear connection/disconnection affordance (e.g. Bluetooth
keyboards).
B. Requests like Bug 25432652. We should not have a rule like A
when a physical keyboard is attached with clear
connection/disconnection affordance (e.g. USB wired keyboards,
2-in-1 convertible tables w/ magnetic contacts).
Currently satisfying both requests at the same time is really difficult
because InputDevice does not have such an attribute. Even with such an
attribute, it's still an open question about how to deal with two or
more keyboards. As a short term solution, this CL add an overlayable
config so that each device can configure which strategy to apply as the
default behavior.
Bug: 26245853
Change-Id: Id2aef6597916422ea63435ae9c31a9a9b5ddf5b8
- The centering is based on the size not including insets, so it should
be offset by the top/left insets.
Bug: 28005632
Change-Id: I114bcaadddb0d4777d4c013097c0d1a20e4fab0b
1. Fix trust agent config does not persist across reboot
2. xxxTrustAgentConfiguration now supported in parent DPM instance
Bug: 27601827
Change-Id: I6ea4a089bf590d6c44be40318f3a69c35c54f796
We should not assume createConfirmDeviceCredentialIntent()
can always return an intent, for example, it has separate work challenge
but lock type is None, then createConfirmDeviceCredentialIntent() will
return null.
Bug: 27782917
Change-Id: I33e40f893f61e35a2e6ce732a47d651139f246a1
If we do not call untether, NetworkController will still think
that wlan0 is part of the LOCAL network, and thus any attempt to
use wlan0 for anything else is doomed to fail.
Bug: 27917299
Change-Id: Ibb63f6b477b85b92281d9667adf8af148deb266c
When an interface is removed, all netlink events for that
interface are lost, because netd will no longer be able to
resolve the ifindex in the netlink event to an interface name,
and it only communicates to the framework events that include an
interface name.
This can cause us to end up with stale IP addresses if, for
example, wlan0 is removed because we switch wifi back from AP
mode to STA mode when exiting tethering. The presence of stale
IPv4 addresses can in turn lead us to miss a provisioning
notification because we already think we have an IPv4 address.
Change-Id: Ib64559a5a4fa261f483760b69fa7996314e7cc17
