| 51e95df8f24e9ea30775686b9e324b9a671213dc |
|
26-Jun-2013 |
Erik Gilling <konkers@android.com> |
Add consumer IR framework
Change-Id: I786c00db0cce61ef75e4edc24e90f2cdcba6dbfb
/frameworks/base/services/jni/onload.cpp
|
| 1af4b0280af406cfc7eb46810f6b76e57b983e11 |
|
13-Jul-2013 |
destradaa <destradaa@google.com> |
Add FlpHal layer to support Location Batching.
Change-Id: Ia3a57d869dfb3f067a1b95fa66d54f311ddcfdc3
/frameworks/base/services/jni/onload.cpp
|
| 26faecc85ec3e809135b287173997e97fcb8fc30 |
|
23-May-2013 |
Todd Poynor <toddpoynor@google.com> |
BatteryService use IBatteryProperties interfaces, drop JNI
IBatteryPropertiesListener binder interface to deliver notifications of
changed battery/power status from healthd system health daemon. healthd
watches uevents from power_supply.
Change-Id: I1ab38622baf28356a6627fe2354b77e2ef99d838
/frameworks/base/services/jni/onload.cpp
|
| 3b748a44c6bd2ea05fe16839caf73dbe50bd7ae9 |
|
18-Apr-2013 |
Romain Guy <romainguy@google.com> |
Pack preloaded framework assets in a texture atlas
When the Android runtime starts, the system preloads a series of assets
in the Zygote process. These assets are shared across all processes.
Unfortunately, each one of these assets is later uploaded in its own
OpenGL texture, once per process. This wastes memory and generates
unnecessary OpenGL state changes.
This CL introduces an asset server that provides an atlas to all processes.
Note: bitmaps used by skia shaders are *not* sampled from the atlas.
It's an uncommon use case and would require extra texture transforms
in the GL shaders.
WHAT IS THE ASSETS ATLAS
The "assets atlas" is a single, shareable graphic buffer that contains
all the system's preloaded bitmap drawables (this includes 9-patches.)
The atlas is made of two distinct objects: the graphic buffer that
contains the actual pixels and the map which indicates where each
preloaded bitmap can be found in the atlas (essentially a pair of
x and y coordinates.)
HOW IS THE ASSETS ATLAS GENERATED
Because we need to support a wide variety of devices and because it
is easy to change the list of preloaded drawables, the atlas is
generated at runtime, during the startup phase of the system process.
There are several steps that lead to the atlas generation:
1. If the device is booting for the first time, or if the device was
updated, we need to find the best atlas configuration. To do so,
the atlas service tries a number of width, height and algorithm
variations that allows us to pack as many assets as possible while
using as little memory as possible. Once a best configuration is found,
it gets written to disk in /data/system/framework_atlas
2. Given a best configuration (algorithm variant, dimensions and
number of bitmaps that can be packed in the atlas), the atlas service
packs all the preloaded bitmaps into a single graphic buffer object.
3. The packing is done using Skia in a temporary native bitmap. The
Skia bitmap is then copied into the graphic buffer using OpenGL ES
to benefit from texture swizzling.
HOW PROCESSES USE THE ATLAS
Whenever a process' hardware renderer initializes its EGL context,
it queries the atlas service for the graphic buffer and the map.
It is important to remember that both the context and the map will
be valid for the lifetime of the hardware renderer (if the system
process goes down, all apps get killed as well.)
Every time the hardware renderer needs to render a bitmap, it first
checks whether the bitmap can be found in the assets atlas. When
the bitmap is part of the atlas, texture coordinates are remapped
appropriately before rendering.
Change-Id: I8eaecf53e7f6a33d90da3d0047c5ceec89ea3af0
/frameworks/base/services/jni/onload.cpp
|
| 64a55af0ac700baecb0877235eb42caac59a3560 |
|
26-Aug-2012 |
Jeff Brown <jeffbrown@google.com> |
Add plumbing for new surface flinger display API.
Cleaned up the implementation of Surface and SurfaceSession
to use more consistent naming and structure.
Added JNI for all of the new surface flinger display API calls.
Enforced the requirement that all Surfaces created by
the window manager be named.
Updated the display manager service to use the new methods.
Change-Id: I2a658f1bfd0437e1c6f9d22df8d4ffcce7284ca2
/frameworks/base/services/jni/onload.cpp
|
| fa25bf5382467b1018bd9af7f1cb30a23d7d59f7 |
|
24-Jul-2012 |
Jeff Brown <jeffbrown@google.com> |
Add display manager skeleton.
The purpose of this change is to remove direct reliance on
SurfaceFlinger for describing the size and characteristics of
displays.
This patch also starts to make a distinction between logical displays
and physical display devices. Currently, the window manager owns
the concept of a logical display whereas the new display
manager owns the concept of a physical display device.
Change-Id: I7e0761f83f033be6c06fd1041280c21500bcabc0
/frameworks/base/services/jni/onload.cpp
|
| b01e8bf57b7492b77e3445db51471edcbadda75e |
|
30-Aug-2011 |
Mike Lockwood <lockwood@android.com> |
New Serial Manager API:
SerialManager: provides access to serial ports
SerialPort: for reading and writing data to and from serial ports
IO with both array based and direct ByteBuffers is supported.
Accessing serial ports requires android.permission.SERIAL_PORT permission
Each platform must configure list of supported serial ports in the
config_serialPorts resource overlay
(this is needed to prevent apps from accidentally accessing the bluetooth
or other system UARTs).
In addition, the platform uevent.rc file must set the owner to the
/dev/tty* files to "system" so the framework can access the port.
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/services/jni/onload.cpp
|
| ec193dec4d9ca2cfc8295c4becfe950a906a15ed |
|
09-Jan-2012 |
Steve Block <steveblock@google.com> |
Rename LOG_ASSERT to ALOG_ASSERT DO NOT MERGE
See https://android-git.corp.google.com/g/157519
Bug: 5449033
Change-Id: I8ceb2dba1b031a0fd68d15d146960d9ced62bbf3
/frameworks/base/services/jni/onload.cpp
|
| 3762c311729fe9f3af085c14c5c1fb471d994c03 |
|
06-Jan-2012 |
Steve Block <steveblock@google.com> |
Rename (IF_)LOGE(_IF) to (IF_)ALOGE(_IF) DO NOT MERGE
See https://android-git.corp.google.com/g/#/c/157220
Bug: 5449033
Change-Id: Ic9c19d30693bd56755f55906127cd6bd7126096c
/frameworks/base/services/jni/onload.cpp
|
| 9302c8796fc4dcda08d4bd1e11733848fd4fafaf |
|
14-Jul-2011 |
Jeff Brown <jeffbrown@google.com> |
Refactor input dispatcher use of window/app handles.
This change moves the cached window and application input state
into the handle objects themselves. It simplifies the dispatcher
somewhat because it no longer needs to fix up references to
transient InputWindow objects each time the window list is updated.
This change will also make it easier to optimize setInputWindows
to avoid doing a lot of redundant data copying. In principle, only
the modified fields need to be updated. However, for now we
continue to update all fields in unison as before.
It turns out that the input dispatcher was inappropriately retaining
pointers to InputWindow objects within the mWindows InputWindow
vector. This vector is copy-on-write so it is possible and the
item pointers to change if an editing operation is performed on
the vector when it does not exclusively own the underlying
SharedBuffer. This bug was uncovered by a previous change that
replaced calls to clear() and appendVector() with a simple use
of operator= which caused the buffer to be shared. Consequently
after editItemAt was called (which it shouldn't have, actually)
the buffer was copied and the cached InputWindow pointers became
invalid. Oops. This change fixes the problem.
Change-Id: I0a259339a6015fcf9113dc4081a6875e047fd425
/frameworks/base/services/jni/onload.cpp
|
| ff3bdca31f4cf2bd607519b276dd175763aa1784 |
|
24-May-2011 |
Chia-chi Yeh <chiachi@android.com> |
The service part of the user space VPN support.
The dialogs will be in another change.
Change-Id: I0cdfd2ef21ffd40ee955b3cbde5ada65dbfdb0bc
/frameworks/base/services/jni/onload.cpp
|
| 46d0adf8256a42416584765625852b6e48497c90 |
|
26-May-2011 |
Mike Lockwood <lockwood@android.com> |
UsbService: Refactor USB host and device support into two separate classes
Host support is in UsbHostManager, device support is in UsbDeviceManager
Renamed UsbDeviceSettingsManager to UsbSettingsManager
Change-Id: Ib76e72957c233fa7f08f454d4d9a2a1da6368cc7
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/services/jni/onload.cpp
|
| 199d1c131d29b5356f71fbd7826a592c1dd8575f |
|
17-Mar-2011 |
James Dong <jdong@google.com> |
Fix missing AOSP copyright headers for more files
o Update the copyright date on InputDispatcher_test.cpp and InputReader_test.cpp
because these two files were moved from other places to the current location,
and were actually created in 2010.
bug - 4119349
Change-Id: Ic93b81ddafb58e9e72a2e9e02ca3d9f173d6dca7
/frameworks/base/services/jni/onload.cpp
|
| e7d511e148bc901ef41ac44d7b3593e5d803f72f |
|
30-Dec-2010 |
Mike Lockwood <lockwood@android.com> |
New APIs for USB host support:
UsbManager:
- is now a service retrievable via Context.getSystemService(Context.USB_SERVICE).
- provides support for returning a list all connected USB devices
- broadcasts ACTION_USB_DEVICE_ATTACHED and USB_DEVICE_DETACHED when devices
are added and removed from the USB host bus
UsbDevice:
- represents an attached USB device.
UsbInterface:
- represents an interface on a USB device
- devices may have multiple interfaces if they provide multiple
sets of functionality (for example, android phones typically have interfaces
for both USB mass storage and adb)
UsbEndpoint:
- represents an endpoint on a USB interface
- endpoints are used for sending or receiving data
(only in one or the other direction)
UsbRequest:
- encapsulates a send or receive request to be sent over an endpoint
Change-Id: Ieef3e434c62760770ea839070cf5eba1a705967a
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/services/jni/onload.cpp
|
| 928e054931d357326613c78e62f4d850b7c442ff |
|
10-Jan-2011 |
Jeff Brown <jeffbrown@google.com> |
Prevent events from getting backlogged.
This change implements two heuristics.
1. When events are older than 10 seconds, they are dropped.
2. If the application is currently busy processing an event and
the user touches a window belonging to a different application
then we drop the currently queued events so the other application
can start processing the gesture immediately.
Note that the system takes care of synthesizing cancelation events
automatically for any events that it drops.
Added some new handle types to allow the native dispatcher to
indirectly refer to the WindowManager's window state and app window
token. This was done to enable the dispatcher to identify the
application to which each window belongs but it also eliminates
some lookup tables and linear searches through the window list
on each key press.
Bug: 3224911
Change-Id: I9dae8dfe23d195d76865f97011fe2f1d351e2940
/frameworks/base/services/jni/onload.cpp
|
| 264f6cd0b9215f75dd5917252abea98e8fce6222 |
|
06-Jan-2011 |
Mike Lockwood <lockwood@android.com> |
Temporarily remove UsbManager support for USB host.
A new USB host API will be added in an upcoming commit
Change-Id: I5816c10c7acd236d31ab8ae255fc83c77121eea0
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/services/jni/onload.cpp
|
| 770126a678ccc9328a89407ffc82f4d998b25427 |
|
10-Dec-2010 |
Mike Lockwood <lockwood@android.com> |
Rename android.hardware.Usb to UsbManager and UsbObserver to UsbService
In preparation for an upcoming change that will make UsbService into a real system service
Change-Id: Id85d624cfc6b10b49a08105cfaaacc667a492c12
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/services/jni/onload.cpp
|
| da39f0e87814c5acb8b6319a1877b93197fb910e |
|
28-Jul-2010 |
Mike Lockwood <lockwood@android.com> |
Send Intents when PTP compatible devices are connected/disconnected to USB
Usb.ACTION_USB_CAMERA_ATTACHED and Usb.ACTION_USB_CAMERA_DETACHED are sent
when cameras are connected and disconnected.
The data field of the intent contains a Uri for the camera in the Mtp content provider.
Change-Id: I814221b4f0507b309997c71edb5a041e8efc54f7
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/services/jni/onload.cpp
|
| 1bf797857e025e8a71db86fb9e79765a767ec1eb |
|
15-Jul-2010 |
Mathias Agopian <mathias@google.com> |
new SensorService
remove old sensor service and implement SensorManager
on top of the new (native) SensorManger API.
Change-Id: Iddb77d498755da3e11646473a44d651f12f40281
/frameworks/base/services/jni/onload.cpp
|
| 00fa7bdd69f0868fd17ea7c881c771d785b2fbbd |
|
03-Jul-2010 |
Jeff Brown <jeffbrown@google.com> |
More native input dispatch work.
Removed old input dispatch code.
Refactored the policy callbacks.
Pushed a tiny bit of the power manager state down to native.
Fixed long press on MENU.
Made the virtual key detection and cancelation a bit more precise.
Change-Id: I5d8c1062f7ea0ab3b54c6fadb058c4d5f5a9e02e
/frameworks/base/services/jni/onload.cpp
|
| 46b9ac0ae2162309774a7478cd9d4e578747bfc2 |
|
23-Apr-2010 |
Jeff Brown <jeffbrown@google.com> |
Native input dispatch rewrite work in progress.
The old dispatch mechanism has been left in place and continues to
be used by default for now. To enable native input dispatch,
edit the ENABLE_NATIVE_DISPATCH constant in WindowManagerPolicy.
Includes part of the new input event NDK API. Some details TBD.
To wire up input dispatch, as the ViewRoot adds a window to the
window session it receives an InputChannel object as an output
argument. The InputChannel encapsulates the file descriptors for a
shared memory region and two pipe end-points. The ViewRoot then
provides the InputChannel to the InputQueue. Behind the
scenes, InputQueue simply attaches handlers to the native PollLoop object
that underlies the MessageQueue. This way MessageQueue doesn't need
to know anything about input dispatch per-se, it just exposes (in native
code) a PollLoop that other components can use to monitor file descriptor
state changes.
There can be zero or more targets for any given input event. Each
input target is specified by its input channel and some parameters
including flags, an X/Y coordinate offset, and the dispatch timeout.
An input target can request either synchronous dispatch (for foreground apps)
or asynchronous dispatch (fire-and-forget for wallpapers and "outside"
targets). Currently, finding the appropriate input targets for an event
requires a call back into the WindowManagerServer from native code.
In the future this will be refactored to avoid most of these callbacks
except as required to handle pending focus transitions.
End-to-end event dispatch mostly works!
To do: event injection, rate limiting, ANRs, testing, optimization, etc.
Change-Id: I8c36b2b9e0a2d27392040ecda0f51b636456de25
/frameworks/base/services/jni/onload.cpp
|
| 00b74270c9f136a8727c5f6cda0997a3a905f385 |
|
26-Mar-2010 |
Mike Lockwood <lockwood@android.com> |
Move files internal to LocationManagerService from framework.jar to services.jar
Change-Id: Iebbfc49b8300ab59730733efdf489ec87ea45a25
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/services/jni/onload.cpp
|
| 3a32213c4029a03fe39486f3d6ebd0ea18928ee1 |
|
24-Nov-2009 |
Mike Lockwood <lockwood@android.com> |
Remove HardwareService and move vibrator support to VibratorService.
The lights support is only needed by PowerManagerService and NotificationManagerService, so we do not need a Binder API for it.
Move backlight and notification light support to new LightsService class.
The camera flash is now handled directly by the camera HAL, so the flash Hardware service flash support is obsolete.
Change-Id: I086d681f54668e7f7de3e8b90df3de19d59833c5
Signed-off-by: Mike Lockwood <lockwood@android.com>
/frameworks/base/services/jni/onload.cpp
|
| 105925376f8d0f6b318c9938c7b83ef7fef094da |
|
19-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake_rel/...@140373
/frameworks/base/services/jni/onload.cpp
|
| b2a3dd88a53cc8c6d19f6dc8ec4f3d6c4abd9b54 |
|
09-Mar-2009 |
The Android Open Source Project <initial-contribution@android.com> |
auto import from //branches/cupcake/...@137197
/frameworks/base/services/jni/onload.cpp
|