This change reuses KeyguardViewMediator for the new Keyguard
implementation in status bar. KeyguardViewManager is replaced by
StatusBarKeyguardManager which handles adding the view, setting the
state etc. StatusBarWindowManager is introduced to managed the window
of the status bar, which has the logic of both the old Keyguard window
and the old status bar window. In the current implementation, Keyguard
gets displayed like it would be in the bouncer state, but that's likely
to change in the future. Also, setHidden in IKeyguardService is also
renamed to setOccluded, as the word hidden interferes with the
terminology when dismissing the Keyguard.
Bug: 13635952
Change-Id: I1c5d5a49d810d8532089f464cb2efe35e577f517
Issue: Unable to turn off Airplane mode from power button
after phone reboot
Fix: Initialize mHasTelephony before the PhoneStateListener is
registered to the TelephonyManager so that correct value
of mHasTelephony is reflected when onServiceStateChanged
callback is called.
Bug: 13697360
Change-Id: Ide8afd9c16ea90b98b5912dbff440c5fd67b178d
This change achieves a couple of things:
- Let Keyguard be a library, so we can use it in SystemUI.
- Introduce FLAG_KEYGUARD for windows and deprecate TYPE_KEYGUARD. Make
all the TYPE_KEYGUARD behaviour dependant on the flag.
- Implement a new KeyguardService in SystemUI, and bind that service
from PhoneWindowManager.
- Introduce BaseStatusBar.setKeyguardState and inflate
KeyguardSimpleHostView there and use FLAG_KEYGUARD for the window, such
that the status bar window essentially gets the Keyguard.
Bug: 13635952
Change-Id: I059d80d8b9b9818a778ab685f4672ea2694def63
When Drawables are inflated during preload (or otherwise without a theme)
they cache their themeable attributes in their constant state as an array
keyed on attribute index. Drawables inflated with a theme will simply
resolve theme attributes as part of normal inflation, and they will not
cache any themeable attributes.
Drawables obtained from Resources are pulled from theme-specific cache
when possible. If an unthemed Drawable exists in the preload cache, a
new constant state will be obtained for the Drawable and the theme will
be applied by resolving the cached themeable attributes and overwriting
their respective constant state properties. If no cached version exists,
a new Drawable is inflated against the desired theme.
Constant states from themed drawables may be cached if the applied theme
is "pure" and was loaded from a style resource without any subsequent
modifications.
This CL does not handle applying themes to several Drawable types, but it
fully supports BitmapDrawable, GradientDrawable, NinePatchDrawable,
ColorDrawable, and TouchFeedbackDrawable.
BUG: 12611005
Change-Id: I4e794fbb62f7a371715f4ebdf946ee5f9a5ad1c9
Previous fix to keep non-show-when-locked windows hid dialogs from
activities that had asked to be show-when-locked. That was too
restrictive.
Fixes bug 13225149.
Change-Id: I39ae9d7cbcc9b5109257f732d027bda3a2de65e4
Previous fix to keep non-show-when-locked windows hid dialogs from
activities that had asked to be show-when-locked. That was too
restrictive.
Fixes bug 13225149.
Change-Id: I39ae9d7cbcc9b5109257f732d027bda3a2de65e4
1. The old introspection model was allowing querying only the active window
which is the one the user is touching or the focused one if no window is
touched. This was limiting as auto completion drop downs were not inspectable,
there was not way to know when the IME toggles, non-focusable windows were
not inspectable if the user taps them as until a screen-reader starts
introspecting the users finger is up, accessibility focus was limited to
only one window and the user couldn't use gestures to visit the whole UI,
and other things I can't remember right now.
The new APIs allow getting all interactive windows, i.e. ones that a
sighted user can interact with. This prevents an accessibility service
from interacting with content a sighter user cannot. The list of windows
can be obtained from an accessibility service or the host window from an
accessibility node info. Introspecting windows obey the same rules for
introspecting node, i.e. the service has to declare this capability
in its manifest.
When some windows change accessibility services receive a new type
of event. Initially the types of windows is very limited. We provide
the bounds in screen, layer, and some other properties which are
enough for a client to determined the spacial and hierarchical
relationship of the windows.
2. Update the documentation in AccessibilityService for newer event types.
3. LongArray was not removing elements properly.
4. Composite accessibility node ids were not properly constructed as they
are composed of two ints, each taking 32 bits. However, the values for
undefined were -1 so composing a 64 long from -1, -1 prevents from getting
back these values when unpacking.
5. Some apps were generating inconsistent AccessibilityNodeInfo tree. Added
a check that enforces such trees to be well formed on dev builds.
6. Removed an necessary code for piping the touch exploration state to
the policy as it should just use the AccessibilityManager from context.
7. When view's visibility changed it was not firing an event to notify
clients it disappeared/appeared. Also ViewGroup was sending accessibility
events for changes if the view is included for accessibility but this is
wrong as there may be a service that want all nodes, hence events from them.
The accessibility manager service takes care of delivering events from
not important for accessibility nodes only to services that want such.
8. Several places were asking for prefetching of sibling but not predecessor
nodes which resulted in prefetching of unconnected subtrees.
9. The local AccessibilityManager implementation was relying on the backing
service being ready when it is created but it can be fetched from a context
before that. If that happens the local manager was in a broken state forever.
Now it is more robust and starts working properly once the backing service
is up. Several places were lacking locking.
bug:13331285
Change-Id: Ie51166d4875d5f3def8d29d77973da4b9251f5c8
- Add new audio restriction layer to app-ops. Restrictions add
additional constraints to audio operations at a stream-level.
Restrictions do not affect the persistable state, and are purely
additive: that is, they can only impose additional contstraints, not
enable something that has already been disabled. Restrictions
also support a whitelisted set of exempt package names.
- Add new audio stream-level checks to app-ops.
- Implement a provisional OP_PLAY_AUDIO suppression to three
java entry points MediaPlayer, AudioTrack, & SoundPool.
- Enhance vibrator api to take stream information as an optional
hint - the constants correspond to AudioManager stream types.
OP_VIBRATE now supports the stream-level restriction check.
- Simplify Vibrator subclasses by adding default implementations
for two .vibrate calls.
- Migrate NoMan's zen-mode control to use the new app-ops
stream-level restriction mechanism.
Change-Id: Ifae8952647202f728cf1c73e881452660c704678
When traversing windows save the fact that windows above the topmost
fullscreen window do not hide the lockscreen. If there is such a
window don't show it.
(cherry picked from commit ab55e524b89c13082193940a5bf8480a2c2522d9)
Fixes bug 13225149.
Change-Id: Ib6f33cbcfb2f60d8957a9184729ecdec80c6a236
When traversing windows save the fact that windows above the topmost
fullscreen window do not hide the lockscreen. If there is such a
window don't show it.
(cherry picked from commit ab55e524b89c13082193940a5bf8480a2c2522d9)
Fixes bug 13225149.
Change-Id: Ib6f33cbcfb2f60d8957a9184729ecdec80c6a236
These new keys behave in similarly to KEYCODE_POWER but do not
simply toggle between awake and asleep states.
Sleep puts the device to sleep if it is awake.
Wakeup wakes up the device if it is asleep.
Bug: 12938999
Change-Id: I260fb918cc858882fe06fa880910df5763a76c5d
When traversing windows save the fact that windows above the topmost
fullscreen window do not hide the lockscreen. If there is such a
window don't show it.
Fixes bug 13225149.
Change-Id: Ib6f33cbcfb2f60d8957a9184729ecdec80c6a236
On some products, it may not make sense to use the accelerometer
to perform auto-rotation. In that case, the product's config.xml
framework resource overlay should set config_supportAutoRotation
to false.
Setting this to false also disables auto-rotation settings.
Bug: 13211999
Change-Id: If9d7d72f2a2c576b14a4ff0afb61ea52c42c3357
Original commit message:
Add swipe-to-dismiss support to PhoneWindow.
This adds a new window feature -- FEATURE_SWIPE_TO_DISMISS -- and a
theme attribute to activate that feature. When the feature is
activated, a SwipeDismissLayout is inflated as the DecorView layout.
SwipeDismissLayout intercepts touch events and steals ones that are
large swipes to the right if its children don't. PhoneWindow
registers handlers that listen for these swipe events, translate the
window when necessary, and finish the activity at the end of the
gesture.
Conflicts:
core/java/android/view/Window.java
core/res/res/values/attrs.xml
Change-Id: I943290b436864ca4a1bd401b88d696e08c921cdd
