When a bugreport is finished, BugreportProgressService sends a
INTENT_BUGREPORT_SHARE intent containing the bugreport pid; then when
the user clicks the share notification, BugreportProgressService uses
the pid to retrieve the bugreport info.
The problem with this approach is that if the service dies before the
user clicks the notification, the bugreport won't be shared.
This change fix this scenario by saving the bugreport info in the share intent.
BUG: 26513652
Also added more logging statements.
Change-Id: Iba86d06369f843ad88194fb1dad0c8b69764df78
- Keep track of original task bounds and scrolled bounds separately,
so that we can reset the scrolling when the it's no longer in effect.
- Calculate the vertical offset for the toast on top half using the
content rect. The original toast position was relative to the bottom
of the content rect, not the display rect.
- Move toast display to prepareSurfaceLocked, as performShowLocked() may
not be called if the app surface is already shown.
related-to: b/26451625
related-to: b/26447921
Change-Id: I82113683c9e3c3beb4938dbd0829d0abf491efd9
When there is scaling, the top/left coordinates are also scaled. They
could be non-zero if the app is being cropped (eg. due to two-finger
scroll).
bug: 26451625
Change-Id: I90d537347b312d2438993780f52b023c2332eb68
Also make sure that the bounds passed to stacks and tasks are not bogus,
as these would mess up the configuration.
Bug: 26512887
Change-Id: I1a3a9c867a2c258a326b31df2bac614ccbb00579
With the updated rolling window of stats for app idleness, we need to make sure
it is populated before we initialize some defaults.
Now that we look at older entries to figure out idleness, if those
entries are in the future (due to time change), set them to the current
screen on time.
Bug:26504153
Change-Id: I4c21e8f094a1a6727373368d043f523053280d7d
am: 099bd9ca8f
* commit '099bd9ca8fea02795424d62c05c723290d68ae14':
In CanvasContext::doFrame, make a separate call to computeFrameTimeNanos and save the result. Then pass that value to UiFrameInfoBuilder::setVsync as both arguments.
am: 35bdda107f
* commit '35bdda107fe76ab62087527946b201551ddfe965':
Animate backlight quickly when display state request to change or power mode changed
Make sure NaturalSurfaceLayout is consistent with SurfaceControl
This case could happen in real world if a non-resizeable activity opens
another activity (eg. Messenger app opens an activity to write up the
message). Need to make sure the new activity is not resized.
Change-Id: I222985fa7ee2cbd94c843ac1190239cce31d3c0c
Keyboard shortcuts are requested via WindowManager, and
the request pipes through to the view root and the window
callback.
Bug: 22405482
Change-Id: Ic0071e91c7b554be3ac9df71e9539ee8a60e822e
Scrolls to the RemoteInputView when it's beneath the IME.
Also fixes ViewRootImpl to take into account translation
when calculating the location of the focused rect.
Bug: 22452379
Change-Id: I9b9649edeabf9bcab8fc487fe92dec62f388737e
Cancel() has apparently never worked. Calling cancel() results
in the startTime being set to Long.MIN_VALUE. In theory, this means that
on the next animation frame (getTransformation()), the elapsed time
(currentTime - startTime) should result in a large positive number, which
is way more than needed to prove that the elapsed fraction is >1 and
therefore that the animation has ended. But in practice, anything subtracting
MIN_VALUE will result in a large negative number due to Long wraparound, so the
end check fails and the animation continues. Forever.
Moreover, event fixing the cancel issue results in a repeating animation
continuing to repeat, because the logic was never there to determine whether
a repeating animation was canceled.
This fix addresses both issues, but in a minimal way. The risk in fixing this
for real is changing the behavior of cancel in a way that existing apps would not
expect. For example, it's weird that cancel causes one more frame to run. And even weirder
that it does so with a negative elapsed duration (resulting in an animation fraction of 0).
But I wouldn't want to change that behavior for fear that I'd break apps who rely on
that weird behavior.
Instead, there's a simple check for for the "expired" check and the "repeat?" check that
sees whether the startTime has the magic value of MIN_VALUE, which should only happen
when an animation has been canceled. If this is the case, it ensures that the animation ends.
For real.
Issue #24984018 canceled animation runs forever
Change-Id: Ia137eb04bd7df3976a4d9cef86fd39a78dc56f39
