Fixed
Status Update
No update yet.
Comments
ar...@google.com
is...@google.com
al...@google.com
Please provide following information which will help us to investigate this further,
* What is the desired behavior of the feature? (Be specific!)
* If relevant, why are current approaches or workarounds insufficient?
* If relevant, what new use cases will this feature will enable?
* What is the desired behavior of the feature? (Be specific!)
* If relevant, why are current approaches or workarounds insufficient?
* If relevant, what new use cases will this feature will enable?
al...@google.com
Desired behavior: When the active display feature activates, currently, the only things shown are the time and any pending notification icons. Desired behavior is including the battery percentage somewhere on the active display as well - whether that is in line with the notification icons, or next to the digital clock, or somewhere else on the screen that is easily noticed by the user. Additionally, it may also be desirable for the contents of the active display to be user-customizable - rather than simply deciding if it is on or off, which are the current options. This would apply both to the active display that shows when the user raises their device (under "Moves") and the ambient display that shows when a user receives a new notification.
Sufficiency of current workaround: there are currently no workarounds for this. User must turn on the display to check the current battery percentage.
New use cases: Adding the battery percentage to the active display will allow users to quickly check their battery level without fully turning on the display.
Sufficiency of current workaround: there are currently no workarounds for this. User must turn on the display to check the current battery percentage.
New use cases: Adding the battery percentage to the active display will allow users to quickly check their battery level without fully turning on the display.
am...@google.com
an...@google.com
We have passed this to the development team and will update this issue with more information as it becomes available.
Description
In support transitions we also have such bug.
Library com.android.support:transition:26.0.0-beta2
In some cases if you apply more than one animators that animate visibility changes it will show two instances of view.
Example project:
Screencast is attached.
Works fine with the code:
TransitionManager.beginDelayedTransition(container,
new TransitionSet()
.addTransition(new Fade())
.addTransition(new Slide(Gravity.RIGHT)));
icon.setVisibility(View.GONE);
But have two "instances" of animated view in that case:
TransitionManager.beginDelayedTransition(container,
new TransitionSet()
.addTransition(new Fade())
.addTransition(new Slide(Gravity.RIGHT)));
container.removeView(icon);
The reason of it that every Visibility transition add the "screenshot" of view to the overlay separately. I think first Visibility transition should add view to the overlay and the second Visibility transition should reuse the same view from overlay and apply animation to it.
I've already fixed the issue in my backport of transitions framework -