Two new public sysui flags for views to request transparent
bars:
View.SYSTEM_UI_FLAG_TRANSPARENT_STATUS
View.SYSTEM_UI_FLAG_TRANSPARENT_NAVIGATION
This first change simply introduces the flags at the framework
level, and makes the requisite layout tweaks to WM.
As part of this change, expunge the term "hideybars" from the
codebase. The flag to declare support for transient bars is called:
View.SYSTEM_UI_FLAG_ALLOW_TRANSIENT
Final visuals/transitions between opaque/transparent bars will be
done as a subsequent change. Right now the transparent style is
identical to the transient bars.
Change-Id: I5ead9c5e7b77f212df5b2a5f6e770596cd2226f3
Refactor the new private virtual display API to also support
creating public virtual displays with various characteristics.
This feature requires special permissions and is only intended
for use by the system.
Change-Id: I44dd19f37cf76ea6d6e313afe42f4a412bd96663
Devices can be configured to remain in their default landscape or
portrait orientation by setting config_forceDefaultOrientation true
in overlay/.../values/config.xml.
Activities that desire to run in the non-default orientation are
supported by creating a logical display within the physical display.
Transitions to and from the activity perform a crossfade rather than
the normal rotation animation.
Also, improve SurfaceTrace debug output.
Fixes bug 9695710.
Change-Id: I053e136cd2b9ae200028595f245b6ada5927cfe9
- default value is "no mirroring"
- introduce android:autoMirrored as a new attribute for Drawable,
BitmapDrawable, LayerDrawable, StateListDrawable and NinePatchDrawable
- setting android:autoMirrored="true" means that the drawable will
be mirrored when the layout direction is RTL (right-to-left)
- also fix an issue with ImageView drawable layout direction not
updated correctly when RTL properties were changed
See bug #7034321 Need Drawable RTL support
Change-Id: If595ee5106c786f38e786d3a032e182f784a9d97
The implementation of getInterpolator() was always returning null
(probably a quick copy-paste from the default Animator implementation).
This patch fixes the problem by returning the interpolator set by
setInterpolator(TimeInterpolator) or the default one if none has been
set yet.
This patch also avoid creating multiple instances of ValueAnimator in
order to retrieve some default values.
Change-Id: I8880f419f021a8b980fb32bebe927915fde19bf7
Calling unFocus() leaves the view hierarchy in an inconsistent
state. This is okay in ViewGroup, where the state is manually
updated, but causes issues in ViewRootImpl.
BUG: 9983358
Change-Id: Id63e62962d895e6bd4f816f202dcf77254ceab4e
Extract audio focus, remote control and media button handling
outside of AudioService without any changes in functionality.
Moving logic to new class, MediaFocusControl.
Introduce interface for managing volum control logic, VolumeController.
The VolumePanel class implements this interface.
Change-Id: I72bda2e0670c26e61ff076fd729c15f9f1156dc5
- Make sure Home activity goes in the correct task and on the correct
stack.
- Do not allow different users to be in the same task.
- Do not set stacks aside for each user.
Fixes bug 9775492.
Change-Id: I0e7954e917aac8482a1015a36923e02914e2b692
This new method on view reflects whether the view has been laid out
at least once since it was attached. hasLayout() seems too vague for that
meaning; every View that has a parent has a layout (since we use container,
parent, and layout interchangeably). The new version of the method
is closer to the actual meaning.
Change-Id: I519745739b6a6317faeb077aa61f994025cf81f3
This change introduces a new measure cache to View, to remember
the measured dimensions for previous pairs of measure specs. The
measure cache is cleared whenever a View requests layout.
Unfortunately some Views rely on measure being always called when
layout is invoked. To work around this problem, we need to remember
when we hit the measure cache to force a call to measure just prior
to calling onLayout(). This does not completely removes all measure
calls but enough to optimize a number of layouts.
Change-Id: Ie085fbcf186e9d7505e1127e0786a12968ebc344
Previously, there were two distinct problems with how delayed
transitions were being run:
- there would be a delay between the transition being put into
a preDrawListener (to be kicked off when that listener fired) and
being removed from the pending list. This allowed another delayed
transition to be run in parallel, which would cause conflicting/
clobbering issues with transition values on the same objects.
- there would be an extra frame delay in some cases due to how/when the
delayed transition would be started. Specfically, we would postOnAnimation()
to call a method that would then add the onPreDraw listener. This two-step
forwarding caused issues noted above.
The fix is to simply add the transition to the preDrawListener immediately, removing
the two-step problem, and also ensuring that the transition is only removed
from the pending list when it is actually started, which prevents other transitions
from starting in the meantime.
Also, added more debug logging to help chase future issues with transitions.
Change-Id: Ie2ff8e73d29f342512842e9641bd8d605e74544c
setMatrix() was crashing in native code, only with hw acceleration on.
concat() would throw a NullPointerException. It now ignores null matrices.
Change-Id: Iebd8b410a957d2ba501570c6fbb3f680ff4a1a23
1. Delayed accessibility events sent when a view subtree changes may be
be delivered after accessibility is disabled leading to a crash. It is
possible that accessibility was disabled while we were waiting for
the timeout before sending the event. Added a check before dispatching.
2. When refreshing a cached node the accessibility node info cache was
not using the correct bypass cache argument value and as result was
not getting the latest node but its cached value. We really want to
get the latest state to update the cache.
3. The debugging cache integrity verification logic was incorrectly
removing nodes from the cache while doing its work.
4. Removed the comments for some debug logging.
bug:9857067
Change-Id: I20ee1a6ffa65ad35457b51d3f2dc0bc5d8d784e6
Looks like an oversight. The other state sets are public, and we
reference this one in the public docs.
Change-Id: I1c2d8bec3cb277ebfb55ccaacefab0cb38703177
Fix links in @throws clauses, typos, redundant "returns"
and use @code for true + false in returns.
Change-Id: Ic3c4c75d6061732d997a386dc3232475c992c188
- This window type can be used for Presentation created on top of virtual
private display.
- There can be PRIVATE_PRESENTATION specific policy / behavior, but for now,
there is nothing special.
Change-Id: I9fde0f0376e57fcc60000d3a3f8657a21ef58993