This reverts commit af0e44885992b0675d7881c391caeff88414695f.
Unblock the release while I figure-out how the change broke things...
Bug: 19505341
Bug: 19507107
Previously we only dumped the time when a broadcast started dispatch.
Start tracking the time when a broadcast was enqueued so that
we can determine whether the broadcast queue was stalled and for
how long. Together with other information in the dump, this can help
to ascertain whether broadcast latency is being caused by the sender,
the dispatcher, or the receiver.
Bug: 17695520
Change-Id: I4f2e4bb92f9178f5d095b9124a15eb2e5f13b9f6
The method cleanupActivityLocked() should be called before
removeActivityFromHistoryLocked(). Previously it didn't matter but
now that we null TaskRecord.stack when removing the last activity
from the task it does.
Fixes NPE in bug 19491381.
Change-Id: Ia6f8f560c0fe4df330577f313e24d7dd02c18409
Also fixed issue with ActivityStackSupervisor.moveTaskToStackLocked()
functionality not working correctly.
Change-Id: Ia13f1e92a7c59ce6543c226533ac8ea623488290
Pressing the back button on the last activity in a stack that isn't
full screen causes the home stack to move forward and hide all other
visible stacks. This change allows the affected stack to be removed
while keeping the other stack visible.
Bug: 19423645
Change-Id: I30d84f84d525c114ee4993c1e4178af70fe47440
- Change the package name from android.midi to android.media.midi
- Add option for specifying a Handler for DeviceCallback notifications
Change-Id: Ia9e9817a651c06299f4e02ee1da3c9666ff64cb9
- When the flag changes, apply an animation from the current value
- When the flag change is caused by an app transition, synchronize
the status bar animation with the app transition animation.
PhoneWindowManager calculates the timings based on some heuristics
of the app transition animations and supplies these timings to
StatusBarService.
Bug: 19233606
Change-Id: I4f99afba8f1eebb3524699ed4d7fbafee5463a37
Introduces the concept of a listener to be notified about app
transition events. The only client at the moment is window manager
which notifies activity manager about completed transitions, but this
can be used for various clients, including the status bar.
Bug: 19233606
Change-Id: Ia6fec5837b6eb4db90f3cb1c999d3f157ba6dd4a
Audio Return Channel hardware circuit was being switched after
the device update initiated by hotplug event. The device instance
was already removed by the time ARC update was attempted, hence
caused an exception.
This CL ensure the config change is done in advance, when
the AVR device instance is still present.
Bug: 19250400
Change-Id: I31cf682f5c8d1a279a0703d10fe182f3da23d3db
Unnecessary rounding up was causing volume change requests
not to be converted to CEC commands occasionally. Removed
the operation.
Bug: 19332158
Change-Id: Ia074722058ada55d46f38aea7a2b915bb5fd2a00
Allow the currently blessed volume controller delegate to access
media session manager to support multiple remote sessions.
Bug: 19260237
Change-Id: I53120f0852c69a7ea08b7b4a9f61902b961dbc70
When the display state is DOZE or DOZE_SUSPEND, assume this means
that the AP may go to sleep at any time so hold a wake lock for
a little while starting when traversals are scheduled to ensure
that the AP remains awake long enough to draw and post the frame
to the display hardware.
This patch is somewhat approximate but should be good enough for
most devices today.
Note that the implementation uses the window manager to ensure that
the window which wants to draw is actually visible before acquiring
the wake lock. There is a cost to this test (a round-trip) which
should not be significant today since we do not expect apps to draw
more than one frame or two while dozing. However, if we wanted to
support animations in general, we might want to optimize it or
eliminate the check altogether (since we can already account for
the app's use of the wake lock).
Another way to implement this functionality might be for the view
hierarchy to listen for the power manager to report that it has entered
a non-interactive power state before deciding to poke draw locks.
This would be somewhat more accurate than watching the display state.
Also, the draw lock timeout logic could be implemented more directly
instead of using an ordinary timed wake lock.
Bug: 18284212
Change-Id: I84b341c678303e8b7481bd1620e634fe82cc4350
Every time the battery level changes, a new extended
detailed use data structure is written to the history.
This currently only contains delta CPU use since the
last detailed entry (total CPU and to three uids), but
it gives us the infrastructure for adding more detailed
data in the future.
A detail entry for regular history looks like:
Details: cpu=15730u+2307s (u0a57=11312u+502s, 1000=2344u+701s, 0=473u+991s)
/proc/stat=15377 usr, 1797 sys, 197 io, 0 irq, 8 sirq, 23103 idle (42.9% of 6m 44s 820ms)
u is user-space cpu time, s is system/kernel time.
The equivalent check-in output is:
9,h,0,Dcpu=15730:2307/10057:11312:502/1000:2344:701/0:473:991
9,h,0,Dpst=15377,1797,197,0,8,23103
Also add a new "unplug" command to the battery service,
to easily put it into a state where it always considers
the device to be running on battery.
Change-Id: Ic76d966f11e592b9dd671879977bf999ebc11eef
- Recognizing that computeScreenConfigurationLocked() only returned
false if mDisplayReady was false allows multiple code
simplifications.
- Make computeNewConfigurationLocked() always return a non-null
value.
- Remove unused Session parameter from removeWindowInnerLocked().
- Just allocate mForceRemoves one time.
- Since ADJUST_WALLPAPER_VISIBILITY_CHANGED was unused have
adjustWallpaperWindowsLocked() return a boolean.
- Remove unused long parameter from handleNotObscuredLocked().
Change-Id: Ifd15736b163ab6e989f8ca32cf8f94b316386216
Also,
* Only restore recent task to a full screen stack instead of any
randomly sized stack.
* Fixed issue where we were restore task from recents for some
operations when we didn't need to.
* Null out TaskRecord.stack when the task is removed from the
stack.
Bug: 19083170
Change-Id: I4e006f101f9d0f2aebde130ad77afc4d258c6612
Problem was caused by getting the canvas from the surface while
within a transaction.
Also, cleaned up code a little so it is clearer what is happening.
Bug: 19249857
Change-Id: I9ff1f612bc8a58a0e0c7939dbb400d083d8a7039
