Addressing some comments:
- Sticky widget is now saved in a user-scoped setting.
- Removed multi-user widget from computation (obsolete).
- Removed status widget from computation (just use right-most).
- Removed duplicate isMusicPlaying logic.
(frameworks/base)
Change-Id: I8ef8f826677d78ac24da52adf2d99d47c8d965ac
Add settings dock_audio_media_enabled indicating if dock audio
is enabled for media for docks that do not implement jack detection.
Bug 7302106.
Change-Id: I75766b606ceb870b3f89979c4e3cca88ed197aaf
This reverts commit 6bf6eb7d5f9207d6a3e1d6b61f17a8654d06fbdb.
and also fbc21e126f329b7b7c161858c1390ccb023be07e
I have also removed all unnecessary calls to resolveLayoutDirection(int). This is possible as
we are resolving layout params on every child of a ViewGroup as of commit
fcc3348f61b2992f0b84e8e8dcb3535fc715298f
Change-Id: I262a375b03fcc3c9261cbe2edebb6ec42ec2e186
- check layout direction previous value in the onResolveDrawables(int) callback
- dont do any Drawables resolution if we cannot resolve the layout direction
- also remove unnecessary call to resolveRtlPropertiesIfNeeded() in ViewGroup when
adding a child as the call to resolveRtlPropertiesIfNeeded() will be done into
the measure() call itself later
Change-Id: I62237af3d307dfea203f7f2865551d1c61a0e0b8
This new API makes it possible for an application to ask on
which Display it should show a Presentation based on the currently
selected media route.
Also added a new API on DisplayManager to query displays that
support a certain category of uses.
Improved the documentation of the Presentation class to explain
how to choose an appropriate Display for presentation.
Bug: 7409073
Change-Id: Iab451215e570ae55f3718fc228303143c800fe51
* commit '3e297339f8b77d54f520d5471c90c9d04e78400e':
FIx bug #7414801 Should make private and final View.TEXT_DIRECTION_DEFAULT and View.TEXT_ALIGNMENT_DEFAULT constants
Add new API to determine whether a display is secure.
Add new API to make a SurfaceView secure.
Clarify documentation.
Bug: 7368436
Change-Id: I7068c34c910e43b4bc72e43fa0dded59a25f0fe2
Bug #7391098
The existing code was doing a make current to guarantee we have a
current context. This can however fail when the surface is destroyed
which could lead to GL calls without an EGL context, and therefore
potential leaks. This change fixes the issue by using a technique
found in HardwareRenderer.destroyHardwareResources(). If the surface
is not available then we use a special 1x1 pbuffer as a way to get
a valid context.
Change-Id: I716d3799bf90120d793d76e90a83956837ecd491
Throw an InvalidDisplayException to addView if the display being
added to has been removed. Handle this exception in Dialog.show()
by removing the view after it has been added and rethrow the
exception from there.
Add javadoc to ViewManager.addView and Presentation.show explaining
the new exception and how best to handle it.
Bug: 7368565 partially fixed. It remains for the Videos app to
handle Presentation.show throwing the InvalidDisplayException.
Change-Id: Ib4303c9b3f7bf7a0cfa95d19bd60a0c128658c48
A bug in software rendering caused animations on views that are offscreen
to not get drawn, therefore the animation doesn't continue (since old-style
animations depend on the logic in the drawing code to keep running). Fix is
to special case the isAnimating case in ViewRoot to go ahead and schedule
a traversal even if the dirty rect does not intersect with the visible region.
Issue #7396035 Animations starting offscreen don't draw run/end/draw properly (sw rendering only)
Change-Id: Iae25b3a424ddc5a16ba431ecd68cf42d5500db3f
