When VideoView calls setFixedSize(), the SurfaceControl.setSize()
gets called from WindowStateAnimator.setSurfaceBoundariesLocked,
but setSurfaceBoundariesLocked only updates the size, not the
transform matrix/scaling factor.
The after some time, SurfaceControl.setMatrix gets called by
WindowStateAnimator.prepareSurfaceLocked. It updates both size and
matrix (size update is skipped since it's already updated by
setSurfaceBoundariesLocked earlier). This corrects the transform
matrix, and restores video rendering.
We now call setMatrix() in setSurfaceBoundariesLocked() to avoid
the glitch.
Bug: 18773834
Change-Id: I5e8de38495fabe54eefa8bd3003627d11392c0f1
When a new package is created, installNewPackageLI does not need to call
dexopt, since it has already been made.
Bug: 19550105
Bug: 20087446
Change-Id: If6b05bea590eea5f95efebb22a67ccd8cdf632c2
The Choreographer carefully schedules animation updates to occur
after input but before traversals occur. This ensures that the
effects of animations are perceived immediately in the next frame.
The start time of animation is usually set the moment the animator
first runs. The start time serves as a reference for timing the
remainder of the animation.
Setting the start time during the animation callback works well except
when traversals take a long time to complete. In that case, we may
end up drawing the initial frame of the animation then skipping several
following frames (because a lot of time has already passed since the
animation start time was set), effectively shortening the duration
of the animation.
To resolve this issue, we introduce a new COMMIT phase within the
Choreographer. The COMMIT callback runs after traversals complete
and may provide an updated frame time that more accurately reflects
the time when the frame finished drawing.
In the case where an animation is just starting, we note the fact
that its initial start time has not yet been committed (the user
hasn't actually seen anything on screen yet). Then, during the
COMMIT phase, we adjust the animation start time to better reflect
the time when the animation's first frame was drawn, effectively
causing the animation actually start after the expensive traversal
operations occurred such that no frames will be skipped.
Bug: 17258911
Change-Id: I279603d01fd4ed1de8f51a77c62f4fec5e9b746a
Since there are no third-party apps expected to be using the visual
voicemail related apps at the moment, best to keep these hidden for now.
Bug: 19236241
Change-Id: I86f622208efcc89fab523f03d2bb70c244cdf867
* commit '47c1835a45321cc327dfd9fc97b3d22305d3fa5e':
docs: Removed instruction to add gms version in manifest during Google Play services setup, since Android Studio automatically handles this. bug: 20077293
* commit '868c795dd253ff31999962f84299be27e4d5828f':
docs: Removed instruction to add gms version in manifest during Google Play services setup, since Android Studio automatically handles this. bug: 20077293
* commit '0307acf90773a16faa6b33dad12b14b95708a3cc':
docs: Removed instruction to add gms version in manifest during Google Play services setup, since Android Studio automatically handles this. bug: 20077293
Also adds a test app for testing this intent. In addition, the secure
camera gets launched in the background to fix jank while sending the
intent.
Bug: 20016619
Change-Id: I7bb7e22ddaf5dc67fc09b9e63e5f3d10fe8e3ee4
If SpanSet.init() is called several times in a row with different
values, it is possible to change "numberOfSpans" in a way that
will prevent SpanSet.recycle() from nulling out all the spans.
This can lead to memory leaks of large objects through spans
references. User @piwai reported this leak:
com.squareup.marketfont.MarketSpan
`-[1] of array android.text.style.CharacterStyle[]
`-spans of object android.text.SpanSet
`-mCharacterStyleSpanSet of object android.text.TextLine
`-[1] of array android.text.TextLine[]
`-sCached of class android.text.TextLine
The MarketSpan instance is kept alive through a recycled TextLine
which itself contains a SpanSet.
Change-Id: Idfb2233ca16895dbe735c312662eaf0b4a2ecd65
