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
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
Switch a few places to using android::canvas
instead of SkCanvas as well which eliminated
some JNI
Change-Id: I8f98b56442a06362b82b984cd1bd3a92398d8dbc
Retain compatibility with implementations compiled
against old headers or left unchanged from LMP.
Change-Id: I3f7cfaaf0cba8697c312940a805b053c6040caa6
Currently GmsCore has to guess how many locations to retrieve
based on requested frequency and then demux the output looking
for timestamps (that aren't monotonically increasing). This
capability gives GmsCore a more graceful solution.
Change-Id: Ie1d71615f699bc0d3c63f8b80aa7b40b9971cf96
Let HAL implementation tell if geofencing/batching is
supported and which technologies (GNNS, wifi, etc)
can be used.
Still todo: Add ability for GmsCore geofencing to
tell which technologies are supported (instead of
just using it to update monitoring). This requires
SystemApi change + approval so will do in separate CL.
Note that the classes in the lib are not copied
directly into GmsCore. The instance will always
be whatever is in the platform. This is why
the callback is backwards compatible as long as
their is a default implementation (but not if
it's abstract).
Change-Id: I7d6adeb049b89935bc4443785df5d7ef4c730e5d
Otherwise, the MIDI device would appear available always, rather than
only when USB is connected.
Also fixed file descriptor leak in UsbMidiDevice
Change-Id: I0d38e81c488de4748eef36ca359635fa59e0e636
MIDI ports are now implemented as file descriptors directly between the sender
and receiver, so the MidiService is no longer in the message path.
To facilitate the above, each port has its own file descriptor, rather than multiplexing
all ports on a device through a single socket.
Added a new class MidiDeviceServer, which is used by implementors of MIDI devices.
This replaces the MidiVirtualDevice class (which only was included in changes that were reviewed but never submitted).
The USB MIDI implementation has moved from the MIDI service to the USB service.
The USB MIDI implementation uses MidiDeviceServer as its interface, so we now have a common
interface for all MIDI device implementations.
Change-Id: I8effd1583f344beb6c940c3a24dbf20b477a6436
Devices may have multiple RTCs. By default the kernel uses rtc0 to
store the system time, but devices may override this (or even specify
that none of them should be used for system time).
Userspace can indirectly find the designated RTC through sysfs. During
AlarmManagerService initialization, enumerate through all rtc class
devices to locate the device with attribute hctosys=1.
This is only done on devices without /dev/alarm, which has its own
in-kernel mechanism to pick the RTC.
Change-Id: Ife2b342c3590133ed316ddaf1799cbc1bfa6e6d9
Signed-off-by: Greg Hackmann <ghackmann@google.com>
