Hide managed profiles from lockscreen user switcher on tablets.
Hide managed profiles from power menu user switcher on phones.
Add flag to enable multi user ui turned off by default.
Change-Id: I4c69a6f7b0f39c249fc85fd940318df1ddab073f
A task is scheduled for deletion after the final activity has
been removed and has animated away. But if another activity is then
added to the task the deletion flag must be reset.
Also added improved debugging.
Fixes bug 12987986.
Change-Id: I207ea6e9592a9e036d67aa5d1465b4acc5bdd120
When a doze component has been specified in a config.xml resource
overlay, the power manager will try to start a preconfigured dream
whenever it would have otherwise gone to sleep and turned the
screen off. The dream should render whatever it intends to show
then call startDozing() to tell the power manager to put the display
into a low power "doze" state and allow the application processor
to be suspended. The dream may wake up periodically using the
alarm manager or other features to update the contents of the display.
Added several new config.xml resources related to dreams and dozing.
In particular for dozing there are two new resources that pertain to
decoupling auto-suspend mode and interactive mode from the display
state. This is a requirement to enable the application processor
and other components to be suspended while dozing. Most devices
do not support these features today.
Consolidated the power manager's NAPPING and DREAMING states into one
to simplify the logic. The NAPPING state was mostly superfluous
and simply indicated that the power manager should attempt to start
a new dream. This state is now tracked in the mSandmanSummoned field.
Added a new DOZING state which is analoguous to DREAMING. The normal
state transition is now: AWAKE -> DREAMING -> DOZING -> ASLEEP.
The PowerManager.goToSleep() method now enters the DOZING state instead
of immediately going to sleep.
While in the doze state, the screen remains on. However, we actually
tell the rest of the system that the screen is off. This is somewhat
unfortunate but much of the system makes inappropriate assumptions
about what it means for the screen to be on or off. In particular,
screen on is usually taken to indicate an interactive state where
the user is present but that's not at all true for dozing (and is
only sometimes true while dreaming). We will probably need to add
some more precise externally visible states at some point.
The DozeHardware interface encapsulates a generic microcontroller
interface to allow a doze dream for off-loading rendering or other
functions while dozing. If the device possesses an MCU HAL for dozing
then it is exposed to the DreamService here.
Removed a number of catch blocks in DreamService that caught Throwable
and attempted to cause the dream to finish itself. We actually just
want to let the process crash. Cleanup will happen automatically if
needed. Catching these exceptions results in mysterious undefined
behavior and broken dreams.
Bug: 12494706
Change-Id: Ie78336b37dde7250d1ce65b3d367879e3bfb2b8b
Instead of keeping track of confirmations per-package, track
a global confirmation per-user. If the panic signal is received,
reshow the cling at most once per-user per-reboot.
Ensure the nav bar becomes visible after the panic signal.
Usually this happens as a side effect of showing the keyguard.
However, in the case where there is no keyguard (Security = None)
show the transient nav bar temporarily as a hint.
Also listen to the correct observer uri to pick up confirmation
setting changes.
Bug:12242125
Change-Id: Ic95e2a8630ec3802b8ef462fcaa92366b9343a3f
Specifically, the ability to force immersive-mode-like behavior
on the status bar, the navigation bar (or both) on a
package-by-package basis - and to disable immersive mode
confirmations for specific packages.
Change-Id: I2df7092a91eceeb815367ef917dd7289f4f2b27e
First pass at API for cross-Activity Scene transitions.
Remaining work:
Transition back
Automatically capture hero element info
Transfer of surface texture to synchronize between Activities
Possibly use scene names to indicate preferred transition
Change-Id: I59d07de1fae694a46b92b1c82525daa301ec1377
With an existing ActivityContainer a caller can now create an
ActivityView which consists of a new VirtualDisplay immediately
attached to the ActivityContainer.
Change-Id: Id70333dcbef55d524a87df8f8c92d72ca5579364
Enable power button end call and screen is off. User use power button
to turn on screen will end call. Should turn on screen and not end call
Change-Id: Idf34f7724dbf1796205332c5c7ef663102f8a30c
Signed-off-by: shower <shower929@gmail.com>
User 0 owns the window (system_server) but should be allowed
to display on a user's behalf.
Use the corresponding private flag for this system window, since
we cannot classify it by type (TYPE_TOAST) in policy.
Bug:12015090
Change-Id: I33aedb4624288415a5e1ae937676b693024546a9
* Add theme attributes for specifying a top-level TransitionManager
for an activity window.
* Add window feature for automatic content transitions. This
automatically assigns/creates a Scene for setContentView calls.
* Add named transitions. This allows apps to define APIs for
handshake-agreements about which exit/entrance transitions to play.
* Add new transition type for ActivityOptions. This lets the system
use ActivityOptions to communicate transition specifics and
arguments to the called activity.
* Have ActivityManager pass appropriate ActivityOptions through to the
called Activity. Have the called activity call back into the caller
to let it know which transition of a possible requested set was
chosen.
Still to do:
* Define and pass arguments for transitions. This will require
defining a Parcelable version of TransitionValues and deciding how
much leeway apps should have for these things.
* Determine how to appropriately filter the ActivityOptions bundle so
that only appropriate data reaches the target.
* Determine if generalizing the auto-Scenes functionality to
ViewGroups is appropriate.
Change-Id: I10684b926129ab2fbc1adec9ef31767237acae79
Remove private WM flag (used only by the volume panel) to force
the clearable system UI flags clear.
Instead, always lay out the volume panel as if the bars are visible,
as we do for system dialogs - and don't clear the flags.
Reverts part of I25f29af5b6518aba695b64a75977ae240b742118
Bug:11986621
Change-Id: I842729d729d2a6eb2a687d0b930ddb160c6a1b57
This fixes a bug where an app calls KeyguardManager.isLocked()
before keyguard has had a chance to show. The fix is to assume
keyguard is showing and secure until we know otherwise.
Fixes bug 11670159
Change-Id: Ifbe4cdf40e3b76d2069ecace940f85fa58f31187
FLAG_FULLSCREEN on the app under the keyguard was keeping
the transient status bar visible if the user locked while
revealing it.
Bug:11629810
Change-Id: I034d3a4f4fe5463702253a1fca6d32debd520c3c
Rather than have a class whose sole job is to pass messages to
PointerLocationView, just have it consume them itself.
Change-Id: I889ce35d99852f746499c0585dc7c43378b4c3a0
An app lib exposed a possible timing problem, causing the bars
to remain hidden after screen rotation during immersive mode.
Bug:11440463
Change-Id: I5166bdce78a876bc08b18f8b9a340366fbbbb70a
Add a window feature for content transitions. This implicitly creates
a Scene for each setContentView operation and runs the appropriate
transition. Applications can specify a TransitionManager XML in their
theme that will apply the appropriate transitions when these implicit
scene changes occur. Apps can specify a "to" with no "from" in a
transition to request an entrance transition for the given
content. This lays the groundwork for further full content
change/activity to activity transitions.
Change-Id: Ic815d9e0b9ce958152d70bf6ee01be075aa9fe88
A final layout pass should be done whenever the status bar has
completed its incoming animation.
Fixes bug 10387660.
Change-Id: I48c19015c53116b58cf73e20be32d1f64dd682ca
When the contextual action bar is not in overlay mode,
the screen layout is a linear layout. (screen_simple.xml)
Ensure the standalone CAB appears below the status bar,
consumes the top offset (to avoid content application below it)
and fill in the status area with a guard view for background
protection.
Bug:10014069
Change-Id: I614f16dfa77367a94808aef54710ffebd66e1ca8
