b0608636a29bcec8ecb4391cd50f29f68b3e7e81 |
|
05-Apr-2017 |
Santos Cordon <santoscordon@google.com> |
Add uniqueId to Virtual Display and pass through to inputflinger (1/2) This CL adds: 1) Adds uniqueId (protected via system/sig permission) to virtual displays. 2) Add support for N virtual display viewports into inputflinger. 3) Set the virtual display's viewports in inputflinger if it has the uniqueId value set to non-null. (a) Moving the new viewport from java to native inputflinger and (b) adding "uniqueId" value to viewports makes up the great majority of this change. 4) From the inputflinger side, we also read in a new value from the input device configuration files called 'touch.displayId'. 5) When touch.displayId and the virtual display's uniqueId match, inputflinger links the two. Test: Start VR and ensure that the virtual viewport shows up when running 'adb shell dump input". Run a VR app, and ensure that the virtual input device is associated with the new virtual viewport. Test: com.android.server.display.DisplayManagerServiceTest Bug: 36051620 Change-Id: Ic2117eb8e19f7f3c59687160591f8bc6692c1f12 Merged-In: Ic2117eb8e19f7f3c59687160591f8bc6692c1f12
/frameworks/base/services/core/jni/onload.cpp
|
df1742ed47da1e9b61afeae16fa448d5302a8aa0 |
|
20-Jan-2017 |
John Reck <jreck@google.com> |
Overhaul GraphicsStatsService * LRU cache of recently-used is dead, replaced disk storage * ASHMEM size is read from native by the system service, no longer requires keeping a sizeof() in sync with a constant in Java * Supports dumping in proto format by passing --proto * Rotates logs on a daily basis * Keeps a history of the most recent 3 days Bug: 33705836 Test: Manual. Verified log rotating works by setting it up to rotate every minute instead of day. Confirmed /data/system/graphicsstats only has the most recent 3 entries after several minutes Change-Id: Ib84bafb26c58701cc86f123236de4fff01aaa4aa
/frameworks/base/services/core/jni/onload.cpp
|
3bf722a8d54ca7192dfe07ee7b73eac7d25ccac5 |
|
15-Dec-2016 |
Rubin Xu <rubinxu@google.com> |
Add synthetic password to authentication flow The user password is used to unlock a per-user synthetic password which serves the purpose of what the user password previsouly achieves (protect keystore, vold disk encryption, auth token generation). Test: runtest frameworks-services -c com.android.server.SyntheticPasswordTests Test: manual 1. Start with fresh device, enable synthetic password with "adb shell cmd lock_settings sp 1" 1.1 add device lock, reboot and verify (positive & negative); change device lock, reboot and verify. 1.2 Inflate a work profile, reboot and verify device lock. check SID with "adb shell dumpsys lock_settings" 1.3 Un-unify and add work challenge, reboot and verify work challenge and SID. 1.4 Re-unify work challenge, reboot and verify. 1.5 Clear device lock, reboot and verify lock and SID. 2. Start with a fresh device, add a device lock and inflate a work profile. 2.1 Enable synthetic password, note current SID 2.2 Reboot and unlock device. Verify synthetic password is generated and SID remains. 2.3 Clear device lock, reboot and verify (SID should be cleared) 3. Start with a fresh device, inflate a work profile, add separate work challenge 3.1 Enable synthetic password, not current SID 3.2 Reboot and unlock device and profile. Verify synthetic password is generated. 3.3 Clear device lock only, reboot and verify (work profile SID should remain) All steps tested on marlin (FBE) and bullhead (FDE) Bug: 33126414 Change-Id: Idb9ebfc7bba2fe40670c5fee2189e873d9704540
/frameworks/base/services/core/jni/onload.cpp
|
2e4e1a17e4fe05a79361fe887d5bf9fadd759231 |
|
21-Dec-2016 |
Wyatt Riley <wyattriley@google.com> |
Treble GNSS - Removing FlpHardwareProvider Removal of legacy FlpHardwareProvider jni, and minimal java implementation. Restoration of GNSS batching functionality, with default implementation using fused_location.h supporting libraries, would continue in the Treble aligned GNSS HAL. Bug: 31974439 Test: Ensured that system boots cleanly, and FLP HAL is not used and that GPS operation (GMaps & 3rd party test app) still looks fine. Change-Id: I7b3834ddd4e754576af30cdbe2a92f53947d85a7
/frameworks/base/services/core/jni/onload.cpp
|
420e45e9cb004ea6c6e11f69adcdbf3dac5fc800 |
|
21-Dec-2016 |
Ashutosh Joshi <ashutoshj@google.com> |
Move ContextHubService to a better location. Move ContextHub service from system core to a more appropriate place for a service. Test: GTS tests pass. Change-Id: Ie0f25414fc472a0214c0dd94e7ad4564cd38f842
/frameworks/base/services/core/jni/onload.cpp
|
3ff1c01cae0b654acd53088634e07e26557edd99 |
|
27-Oct-2016 |
Daichi Hirono <hirono@google.com> |
Add AppFuseBridge class to the system service. Bug: 29970149 Test: None Change-Id: I1d40d8e3aec1c57a31d5ae66b33305990dc86b67
/frameworks/base/services/core/jni/onload.cpp
|
253f2c213f6ecda63b6872aee77bd30d5ec07c82 |
|
29-Sep-2016 |
Romain Guy <romainguy@google.com> |
Linear blending, step 1 NOTE: Linear blending is currently disabled in this CL as the feature is still a work in progress Android currently performs all blending (any kind of linear math on colors really) on gamma-encoded colors. Since Android assumes that the default color space is sRGB, all bitmaps and colors are encoded with the sRGB Opto-Electronic Conversion Function (OECF, which can be approximated with a power function). Since the power curve is not linear, our linear math is incorrect. The result is that we generate colors that tend to be too dark; this affects blending but also anti-aliasing, gradients, blurs, etc. The solution is to convert gamma-encoded colors back to linear space before doing any math on them, using the sRGB Electo-Optical Conversion Function (EOCF). This is achieved in different ways in different parts of the pipeline: - Using hardware conversions when sampling from OpenGL textures or writing into OpenGL frame buffers - Using software conversion functions, to translate app-supplied colors to and from sRGB - Using Skia's color spaces Any type of processing on colors must roughly ollow these steps: [sRGB input]->EOCF->[linear data]->[processing]->OECF->[sRGB output] For the sRGB color space, the conversion functions are defined as follows: OECF(linear) := linear <= 0.0031308 ? linear * 12.92 : (pow(linear, 1/2.4) * 1.055) - 0.055 EOCF(srgb) := srgb <= 0.04045 ? srgb / 12.92 : pow((srgb + 0.055) / 1.055, 2.4) The EOCF is simply the reciprocal of the OECF. While it is highly recommended to use the exact sRGB conversion functions everywhere possible, it is sometimes useful or beneficial to rely on approximations: - pow(x,2.2) and pow(x,1/2.2) - x^2 and sqrt(x) The latter is particularly useful in fragment shaders (for instance to apply dithering in sRGB space), especially if the sqrt() can be replaced with an inversesqrt(). Here is a fairly exhaustive list of modifications implemented in this CL: - Set TARGET_ENABLE_LINEAR_BLENDING := false in BoardConfig.mk to disable linear blending. This is only for GLES 2.0 GPUs with no hardware sRGB support. This flag is currently assumed to be false (see note above) - sRGB writes are disabled when entering a functor (WebView). This will need to be fixed at some point - Skia bitmaps are created with the sRGB color space - Bitmaps using a 565 config are expanded to 888 - Linear blending is disabled when entering a functor - External textures are not properly sampled (see below) - Gradients are interpolated in linear space - Texture-based dithering was replaced with analytical dithering - Dithering is done in the quantization color space, which is why we must do EOCF(OECF(color)+dither) - Text is now gamma corrected differently depending on the luminance of the source pixel. The asumption is that a bright pixel will be blended on a dark background and the other way around. The source alpha is gamma corrected to thicken dark on bright and thin bright on dark to match the intended design of fonts. This also matches the behavior of popular design/drawing applications - Removed the asset atlas. It did not contain anything useful and could not be sampled in sRGB without a yet-to-be-defined GL extension - The last column of color matrices is converted to linear space because its value are added to linear colors Missing features: - Resource qualifier? - Regeneration of goldeng images for automated tests - Handle alpha8/grey8 properly - Disable sRGB write for layers with external textures Test: Manual testing while work in progress Bug: 29940137 Change-Id: I6a07b15ab49b554377cd33a36b6d9971a15e9a0b
/frameworks/base/services/core/jni/onload.cpp
|
a712d4058f6f85268838710857e6070a739cf6f9 |
|
07-Sep-2016 |
Todd Kjos <tkjos@google.com> |
Revert "Enable migration to big cores for app launches." This reverts commit a326a116f7f9fb939fac3d28c80d32542016decc. Change-Id: I9f9497990fbf0697d05445f563ad46a28d6d6eeb
/frameworks/base/services/core/jni/onload.cpp
|
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
|