Applications sometimes crashed on exit due to the display event
receiver pipe apparently being closed while still a member of the
Looper's epoll fd set.
This patch fixes a few different possible races related to
the display event receiver lifecycle.
1. The receiver used to play a little dance with the Looper,
registering and unregistering its callback after each vsync
request. This code was a holdover from a time before the
surface flinger supported one-shot vsync requests, so we can
get rid of it and make things a lot simpler.
2. When the Choreographer is being accessed from outside the UI
thread, it needs to take great care that it does not touch
the display event receiver. Bad things could happen if the receiver
is handling a vsync event on the Looper and the receiver is
disposed concurrently.
3. It was possible for the Choreographer to attempt to dispose
the receiver while handling a vsync message. Now we defer disposing
the receiver for a little while, which is also nice because we
may be able to avoid disposing the receiver altogether if we find
that we need it again a little while later.
Bug: 5974105
Change-Id: I77a158f51b0b689af34d07aee4245b969e6260d6
This tool lets you visualize the time it took, in ms, to:
- Build display lists ("Draw" phase)
- Process display lists ("Process" phase)
- Swap GL buffers ("Execute" phase)
To use this tool:
- adb shell setprop hwui.profile true
- adb shell dumpsys gfxinfo <process name>
- Copy the profile data and paste it in a spreadsheet
- Generate a graph (stacked graph) and enjoy
Change-Id: I7840c0ea0f153550425aa798e3ada2f357688cf5
Some of the ongoing and upcoming jank work involves having
Views optimize their rendering. For example, it would be more
efficient for native display lists to be able to redraw themselves with
updated transform/alpha properties than it would be to do it the
way we do now, which causes view hierarchy invalidation and display
list recreation.
In order to do this, we need to push more intelligence for view
rendering into the Views themselves, rather than the complicated
mechanism we have now of ViewGroup handling some View properties
(transforms and alpha) and the Views handling the rest of their
rendering.
The first step toward this is to take the current drawChild() method
and push it into a new, package-private method in View that does the
same thing.
Future checkins will refactor the code further, simplifying it and
eventually optimizing around view property changes.
Change-Id: Id44b94536fc3ff80b474db7ef06862f4f51eedce
This change allows layouts to be notified of changes to LayoutParameters that have occurred
between layout operations.
If an assignment is made to the fields of LayoutParams instances that are already in use,
cachced data may become inconsistent with the new values. For complex layouts, like
GridLayout, in which the layout parameters define the structure of the layout, caching
could have caused ArrayOutOfBoundsException to be raised without this change. This case is
rare in normal code as initialisation is typically performed once. Its nevertheless possible
and much more likely in environments like design tools where layout parametrs may be being
edited on the fly.
Prevent errors as follows (belt and braces):
1. Change javadoc to request that changes to the fields of LayoutParams be accompanied with
a call to View.setLayoutParams(). (This calls requestLayout() which was what the previous
javadoc advised.) Provide a (for now, private) hook for layouts with caches to receive notification
of such calls so they can invalidate any relevant internal state.
2. For GridLayout, we cannot clone layout parameters as traditional Java grids do without retaining
two complete copies because of the public getLayoutParameters() method on View. Retaining two
copies is wasteful on constrainted devices. Instead, we keep just one copy and compute a hashCode
for the critical fields of a GridLayout's layoutParams. The hashChode is checked it prior to all
layout operations; clearing the cache and logging a warning when changes are detected, so that
developers can fix their code to provide the call to setLayoutParams() as above.
Change-Id: I819ea65ec0ab82202e2f94fd5cd3ae2723c1a9a0
- update also DEBUG mode for taking care about RTL
- one minor issue remaining: left alignment is not properly honored in RTL
Change-Id: I9a4c8413cb1189a032649472016994642418637b
To support this feature, the input dispatcher now allows input
events to be acknowledged out-of-order. As a result, the
consumer can choose to defer handling an input event from one
device (because it is building a big batch) while continuing
to handle input events from other devices.
The InputEventReceiver now sends a notification when a batch
is pending. The ViewRoot handles this notification by scheduling
a draw on the next sync. When the draw happens, the InputEventReceiver
is instructed to consume all pending batched input events, the
input event queue is fully processed (as much as possible),
and then the ViewRoot performs traversals as usual.
With these changes in place, the input dispatch latency is
consistently less than one frame as long as the application itself
isn't stalled. Input events are delivered to the application
as soon as possible and are handled as soon as possible. In practice,
it is no longer possible for an application to build up a huge
backlog of touch events.
This is part of a series of changes to improve input system pipelining.
Bug: 5963420
Change-Id: I42c01117eca78f12d66d49a736c1c122346ccd1d
Previously we were starting DHCP as soon as the interface was added,
which is at boot on devices with builtin ethernet.
Signed-off-by: Mike Lockwood <lockwood@google.com>
This allows Music2 and other media apps to control master volume without changing their code
Bug: 5567694
Signed-off-by: Mike Lockwood <lockwood@android.com>
- Allow each user to have their own wallpaper (live or static).
- Migrate old wallpaper on upgrade.
- Update SystemBackupAgent to backup/restore from primary user's
new wallpaper directory.
Reduce dependency on Binder.getOrigCallingUser() by passing the
userId for bindService.
Change-Id: I19c8c3296d3d2efa7f28f951d4b84407489e2166
Using the same convention in system_init.cpp, you can disable these
services by setting system properties:
system_init.startaudioservice=0
system_init.startmountservice=0
Signed-off-by: Mike Lockwood <lockwood@android.com>
* changes:
Fix problems dispatching media button events on headless devices
Add headless mode for running the framework without the surface flinger
SettingsProvider: Allow overridding default value for Setttings.Secure.DEVICE_PROVISIONED
Load lockscreen.disabled setting on database create as well as upgrade
SystemUI: Log an error instead of throwing an exception if navigation bar is enabled in tablet UI
SettingsProvider: Add support for overriding lockscreen.disabled default value
Allow overriding default STAY_ON_WHILE_PLUGGED_IN setting value in an overlay
Disable output processing when opening serial port.
Update aidl for new Broker API.
aidl: All flattenable types now must also be parcelable.
Update aidl to new APIs.
Suport RpcData as a parcelable type.
Modified AIDL to support authentication
Fix disconnect from wired ethernet issues.
Fix PresenterClass by adding a _listener field
add presenters to aidl.
Add SerialPort.sendBreak()
Generate fallthrough for unhandled actions in RPC methods.
PhoneWindowManager: Disable boot progress dialog on headless builds
Support custom flattenable types for RPC.
SystemServer: Don't start A2DP service if audio is not enabled
Add RpcData as a built-in marshallable type.
Add the full suite of RpcData types.
Checkpoint adding @home RPC support to aidl
ActivityManager: Make sure BOOT_COMPLETED Intent is sent when running headless
When a cable was unplugged, we were telling the driver to release the
ip address so if a cable on a different network was plugged in, it would
still try to use it's old ip address on the new network, which probably
didn't work.
Also, we didn't notify ConnectivityService about the state change in
the unplug case. Some of this was done in the interface removed case,
but we never remove the interface in Tungsten, just unplug. So refactor
the common disconnect code into a disconnect() function that's called
by both the link status change (unplug) and interface removal (only applies
to things like USB ethernet dongles) cases.
Signed-off-by: Mike J. Chen <mjchen@google.com>
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>
Services now must explicitly opt in to being accessed by isolated
processes. Currently only the activity manager and surface flinger
allow this. Activity manager is needed so that we can actually
bring up the process; SurfaceFlinger is needed to be able to get the
display information for creating the Configuration. The SurfaceFlinger
should be safe because the app doesn't have access to the window
manager so can't actually get a surface to do anything with.
The activity manager now protects most of its entry points against
isolated processes.
Change-Id: I0dad8cb2c873575c4c7659c3c2a7eda8e98f46b0
