History log of /frameworks/base/services/core/jni/onload.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
b5b86c11008422ac4bf5af5fed736f04ebbaa858 29-Jan-2016 Sujith Ramakrishnan <sujithrk@google.com> Unbundle RemoteService on TV - part 3

- New service TVRemoteService triggered by SystemServer
- Provider service proxy and watcher for maintaining connections to unbundled
services which have the BIND_TV_REMOTE_SERVICE permission.
- Shared library to facilitate connections between unbundled service and
TVRemoteService.
- Unbundled service needs TV_VIRTUAL_REMOTE_CONTROLLER
permission to be fully functional.

b/23792608

Change-Id: Ief5c6995883d1f7268a73bdd0c920c4c3f42cddb
/frameworks/base/services/core/jni/onload.cpp
f8754ac2127f8adf40bd4731f39b16340acdb2f7 12-Feb-2016 Polina Bondarenko <pbond@google.com> Added hardwareproperties SystemService

Add HardwarePropertiesManagerService which call native methods to
get CPU, GPU, battery temperatures, CPU usage info, fan speeds.
Restrict hardware properties retrieval only for device and profile
owners.

Bug: 26945055
Change-Id: I4d6b30b78e575532d5e9cfa59ef6cd81355439d4
/frameworks/base/services/core/jni/onload.cpp
baa4b55b892041fc33f3acdf29de0676ab63c2f9 03-Feb-2016 Ruben Brunk <rubenbrunk@google.com> Connect VR HAL to VrManagerService.

- Implement lifecycle calls into HAL from VrManagerService.

Bug: 22855417
Change-Id: I7b8144621ffcd44470d0ed3e6b137fffb081a21a
/frameworks/base/services/core/jni/onload.cpp
30f95a7d67870c28d2aaa88ee989c099f5670225 08-Jan-2016 Lifu Tang <lifu@google.com> Supported GNSS multi-constellation in frameworks

Change-Id: I82574afd3697c47e806d2cfaedc33756d0353b73
/frameworks/base/services/core/jni/onload.cpp
a326a116f7f9fb939fac3d28c80d32542016decc 25-Aug-2015 Tim Murray <timmurray@google.com> Enable migration to big cores for app launches.

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
/frameworks/base/services/core/jni/onload.cpp
be67542182e41a6e31cf002db72ec42ee717bd1c 12-May-2015 Jim Miller <jaggies@google.com> Move from native FingerprintService implementation to fingerprintd

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
/frameworks/base/services/core/jni/onload.cpp
10024b3dc12a8552c1547b67810c77b865045cc8 11-Dec-2014 Mike Lockwood <lockwood@google.com> MidiManager updates:

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
/frameworks/base/services/core/jni/onload.cpp
184e3ed0f094ecb6cb8130a135ba8a8e9e51803a 30-Sep-2014 Andreas Gampe <agampe@google.com> resolved conflicts for merge of 6290c048 to lmp-mr1-dev-plus-aosp

Change-Id: I2551a233079c2be562ba37dc7413d59ce4e7bf83
781041239f2931ca16c902fb371cd041b057c918 26-Aug-2014 Jinsuk Kim <jinsukkim@google.com> CEC: Stub MHL Controller

Replace MHL Controller with a stub impl

Bug: 17259897

Change-Id: Id57bac363441f72b3da3f30d31c68c6d3b502237
/frameworks/base/services/core/jni/onload.cpp
29564cd24589867f653cd22cabbaac6493cfc530 07-Aug-2014 Narayan Kamath <narayan@google.com> Remove system_server classes from the boot image.

We set the system_server classpath in the environment
(like we do with BOOTCLASSPATH). After the zygote forks
the system_server, we dexopt the classpath (if needed)
and then launch the system server with the correct
PathClassLoader. This needed several small / medium
refactorings :

- The logic for connecting to installd is now in a separate
class and belongs in the system_server.
- SystemService / SystemServiceManager have now moved to
classes.jar. They are only used from there, and since they
use Class.forName, we want them to be loaded by the
system_server classloader, and not the bootclassloader.
- BootReceiver now moves to frameworks.jar, because it is
used by ActivityThread and friends.

bug: 16555230

Change-Id: Ic84f0b2baf611eeedff6d123cb7191bb0259e600
/frameworks/base/services/core/jni/onload.cpp
0f208eb707926f0afc1ce073be866bedd4955aa2 27-Jul-2014 Jeff Brown <jeffbrown@google.com> Remove DozeHardware since it will not be used.

Bug: 16516536
Change-Id: I14597d3c9470c94e3bc5b8cff500d2fe6b2fd977
/frameworks/base/services/core/jni/onload.cpp
68d4acd205e8c2da524e62734ca42847306cc029 02-Jul-2014 Andres Morales <anmorales@google.com> Service for reading and writing blocks to PST partition

Permits apps with permission
android.permission.ACCESS_PERSISTENT_PARTITION to obtain
a read and write data blocks to the PST partition.

Only one block ever exists at one time in PST. When
a client writes another block, the previous one is
overwritten.

This permits storing a block of data that will live
across factory resets.

Change-Id: I8f23df3531f3c0512118eb4b7530eff8a8e81c83
/frameworks/base/services/core/jni/onload.cpp
3f48068d782b81dc1c8a0190b91fbb2862007244 06-Jun-2014 Jinsuk Kim <jinsukkim@google.com> Remove HdmiCecService

The service is replaced with HdmiControlService. Removing all the related
classes and the initialization of the service.

Change-Id: Ic7baaddffb9873613ddd1096e874f226da983939
/frameworks/base/services/core/jni/onload.cpp
c22dbb69194c8e8fe2a32326d1f37a738cad0904 26-May-2014 Wonsik Kim <wonsik@google.com> Revert "Revert "Add physical TV input handling to TvInputManagerService""

This reverts commit 1940e197a8de186df5edf0b78e0907ae539bd215.

Bug: 14118245, Bug: 15197740
Change-Id: Ia308f16d2ed8ec55112a4d21c180ccb97e8d7c6a
/frameworks/base/services/core/jni/onload.cpp
0792d37385e60aa8d73f8df174d0a32f4f618bc4 23-Apr-2014 Jungshik Jang <jayjang@google.com> Implement skeleton of new HDMI Control Service.

HdmiCecService is a system service handling HDMI-CEC features
and command. Recently we found out that industry has more
requirements to support HDMI-CEC. Also, MHL is another
standard should be in our pocket. Basically, MHL is
a standard to support communication between mobile device
and TV or Av device. As CEC is a control standard over HDMI
cable, MHL has control channel for peer device.
There behavior is very similiar. Both have commands that
can change Tv's current input and can send/receive key
to other device to control other deivce or TV.

In order to cover both CEC and MHL, current HdmiCecService
implementation has limitation. We had several
session of discussion and decided to refactor
HdmiCecService into HdmiControlService.
For each standard it will have separate controller instance
like HdmiCecController and HdmiMhlController.

In this change I didn't touch original HdmiCecService
because some component, like cast receiver, uses HdmiCecService.
For a while we will keep HdmiCecService until HdmiControlService
accomodates all features of HdmiCecService.

Change-Id: I5485280ab803dbf071d898bfbe34be0b11ce7958
/frameworks/base/services/core/jni/onload.cpp
a42cb8b0e2b8fdfbac1a6590d6b60814caa01088 21-Mar-2014 Colin Cross <ccross@android.com> resolved conflicts for merge of a67e34c8 to master

Change-Id: I597525886260884c9b2dfc7945e01eb8138a58c2
4f512fb451c8ddcea852645c5c24314c20c0974b 28-Feb-2014 Jinsuk Kim <jinsukkim@google.com> Add HDMI-CEC service

This CL adds a system service handling HDMI-CEC protocol. The service
is equipped with the capability sending/receiving HDMI-CEC messages

Not all the messages are in place. Currently it has messages to support
a few features only, as follows:

- One touch play
- System information
- Routing control (partially - active source status maintenance only)
- Device OSD transfer
- Power status

It will be extended to cover the wider usages in the follow up CLs.

The CEC standard version referenced in the implementation is 1.3a.

Change-Id: Ifed0b02f52ebf098eddb3bd0987efbf353b7e8fe
/frameworks/base/services/core/jni/onload.cpp
c51cf03cf2458c8c137f60c7379f2cccf681d16f 03-Mar-2014 Dianne Hackborn <hackbod@google.com> Start recording wakeup reasons in battery history.

Depends on a modification to libsuspend so that we can get
a callback each time the device wakes up, to read the current
wakeup reasons from the kernel. These are then stuffed in
to a new field in the battery history.

Also add new dump options --history-start and --charged
to better control what is dumped.

Finally the alarm manager uses a "*walarm*" tag for history
item wake locks that are coming from a wakeup alarm.

Change-Id: I457571973d5b2b5fdc4e4b63ab16275db20d7edd
/frameworks/base/services/core/jni/onload.cpp
2687550272ba061448f5d5b914700dc335299ee7 31-Jan-2014 Jeff Brown <jeffbrown@google.com> Add a new "doze mode" based on Dream components.

When a doze component has been specified in a config.xml resource
overlay, the power manager will try to start a preconfigured dream
whenever it would have otherwise gone to sleep and turned the
screen off. The dream should render whatever it intends to show
then call startDozing() to tell the power manager to put the display
into a low power "doze" state and allow the application processor
to be suspended. The dream may wake up periodically using the
alarm manager or other features to update the contents of the display.

Added several new config.xml resources related to dreams and dozing.
In particular for dozing there are two new resources that pertain to
decoupling auto-suspend mode and interactive mode from the display
state. This is a requirement to enable the application processor
and other components to be suspended while dozing. Most devices
do not support these features today.

Consolidated the power manager's NAPPING and DREAMING states into one
to simplify the logic. The NAPPING state was mostly superfluous
and simply indicated that the power manager should attempt to start
a new dream. This state is now tracked in the mSandmanSummoned field.

Added a new DOZING state which is analoguous to DREAMING. The normal
state transition is now: AWAKE -> DREAMING -> DOZING -> ASLEEP.
The PowerManager.goToSleep() method now enters the DOZING state instead
of immediately going to sleep.

While in the doze state, the screen remains on. However, we actually
tell the rest of the system that the screen is off. This is somewhat
unfortunate but much of the system makes inappropriate assumptions
about what it means for the screen to be on or off. In particular,
screen on is usually taken to indicate an interactive state where
the user is present but that's not at all true for dozing (and is
only sometimes true while dreaming). We will probably need to add
some more precise externally visible states at some point.

The DozeHardware interface encapsulates a generic microcontroller
interface to allow a doze dream for off-loading rendering or other
functions while dozing. If the device possesses an MCU HAL for dozing
then it is exposed to the DreamService here.

Removed a number of catch blocks in DreamService that caught Throwable
and attempted to cause the dream to finish itself. We actually just
want to let the process crash. Cleanup will happen automatically if
needed. Catching these exceptions results in mysterious undefined
behavior and broken dreams.

Bug: 12494706
Change-Id: Ie78336b37dde7250d1ce65b3d367879e3bfb2b8b
/frameworks/base/services/core/jni/onload.cpp
9158825f9c41869689d6b1786d7c7aa8bdd524ce 22-Nov-2013 Amith Yamasani <yamasani@google.com> Move some system services to separate directories

Refactored the directory structure so that services can be optionally
excluded. This is step 1. Will be followed by another change that makes
it possible to remove services from the build.

Change-Id: Ideacedfd34b5e213217ad3ff4ebb21c4a8e73f85
/frameworks/base/services/core/jni/onload.cpp