* Adjust position of target IME resized window if it is been obscured
by the IME.
* Make sure resized window frame is within content frame so it doesn't
extend to the screen decoration regions.
Bug: 19424276
Bug: 19500488
Change-Id: I561338101697e10ea5072ee65a180dd0155d0da4
performDexOptLibsLI and related methods were extracted to PackageDexOptimizer
class. Minor refactoring of PackageManagerService.
This is a non-functional change. It should simplify further work to allow
storing OAT files inside package dir.
Change-Id: I3494a2da70605362bb6fb4625ffbee1cbe1cd457
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
