Try multiple times to open the MIDI control device.
This fixes a race condition that caused Android to
sometimes not see a USB MIDI keyboard when it was plugged in.
Bug: 25328161
Change-Id: Ic72c5859364fc56bf7a40c1b1c9791c42827ea63
Signed-off-by: Phil Burk <philburk@google.com>
Right now, it only supports I-beam on EditText, but further
rules will come in the future.
The png files for the icons are from chromium.
Bug: 24180385
Change-Id: I8de4ec8a5412b4830c08aa232c5083841c5c751c
Ensures that the GPS and FLP HAL interfaces are deinitialized upon
system shut-down. This gives a chance for the underlying HAL to
close cleanly any resources it could be holding.
Note this approach only works for a device's power-off, scenarios
such as adb shell stop / start cannot be handled, because in such
cases the process is terminated sending SIGKILL to it.
Bug: 23279835
Bug: 23279593
Change-Id: I29b3306c0ae2b384d0542031080a15fdbe49dd71
Uses cpusets to move all foreground tasks to the big cores in order
to improve overall app launch latency. Big cores will be used for
three seconds, and then the cpuset assignment is reset, allowing
foreground tasks to fall back to the little cores as appropriate.
Associated system/core and device/* changes in order to enable
the boost cpuset and configure it per-device.
bug 21915482
Change-Id: Id8a0efcb31950c1988f20273ac01c89c8c948eaf
Wakeup reasons come from drivers and sometimes are malformed UTF-8.
Decode them in Java so we can easily replace malformed characters
and still have user visible strings.
Bug:22368519
Change-Id: Ifade1a7fcdf6545e7e344d74390200c329430e14
Volatile doesn't provide any guarantees with respect to write
visibility, so it's possible that PowerManager will tell InputManager
about a change in interactivity state, but the actual dispatching
thread will never observe it.
Also, add logging about NativeInputManager state.
Bug: 22422588
Change-Id: Ifc3add992b9009d920d80a0315ff89c9574be20d
When calling the methods
com_android_server_PersistentDataBlockService_getBlockDeviceSize()
com_android_server_PersistentDataBlockService_wipe()
memory is leaked because string created by
GetStringUTFChars() is not released.
Use ScopedUtfChars instead to ensure that memory is released.
Change-Id: I880a6d66a4824778b411b858774b8ffa009c1e17
This should fix contention problems for apps using USB APIs to implement MIDI support
Bug: 20949468
Bug: 21630625
Change-Id: I32b44330ca0310a4693fd56a4b01ad399f82c1c9
Previously if we were initializing the wakeup callback for the first time,
we would read the wakeup_reason file and ignore the contents, sending a
wakeup_reason of "unknown" up to BatteryStats.
Now we initialize the callback and wait on it immediately. Wakeup reasons are reset
when we go into sleep, so when we wakeup, we will always have fresh wakeup reasons.
Bug:21665793
Change-Id: I20832d8a143fc2715915fcecf4bb71980f279440
b/21516868
This change makes AGpsStatus_v3 consistent and compatible with the behavior
of AGpsStatus_v2.
Change-Id: Ia4e729d8ed1d61b51ae22c7eaf9bbe33f31b7a45
This adds a new service, fingerprintd, that manages fingerprint
hardware from a separate process. It provides a binder interface that
FingerprintManager uses to talk to the fingerprint HAL.
Change-Id: I84d8e407c1f1a7d1a396e246c382459ad38810ae
Switch a few places to using android::canvas
instead of SkCanvas as well which eliminated
some JNI
Change-Id: I8f98b56442a06362b82b984cd1bd3a92398d8dbc
Stop assuming that a Java Bitmap has a SkBitmap* that
has some externally managed lifecycle, and instead switch
a bunch of users to accessing the bitmap by providing
their own SkBitmap* on which to set the (ref counted!)
SkPixelRef* instead
Attempt #2 to land this, original issue was in getSkBitmap
and should be fixed
Change-Id: I0fd9e193968b41e5597784140d56b4885906864a
b/19271554
Prevents accessing and computing data in cases when we know that the result
cannot be used by the GPS HAL, because the required interface is not supported.
Change-Id: I74bf1719f2c8ab7fbfe1244ebe0bebe3ed55ba24
