This adds a new service for monitoring and enrolling fingerprints
to the platform.
Fixed documentation links.
Change-Id: I66013be5e09be9c5f9746c46aacf32d3e26c3b73
Move the window swipe to dismiss plumbing off of Window.Callback into
its own internal interface implemented by Activity and Dialog. Make it
internal API instead of public. Apps should control this via the
window feature setting.
Change-Id: I64cd237fa7eab08719b2c34e31dac7d34f02563a
This makes VoiceInteractionSession a more first-class
concept. Now the flow is that a VoiceInteractionService
calls startSession() when it wants to begin a session.
This will result in a new VoiceInteractionSession via the
VoiceInteractionSessionService containing it, and the
session at that point an decide what to do. It can now
show UI, and it is what has access to the startVoiceActivity
API.
Change-Id: Ie2b85b3020ef1206d3f44b335b128d064e8f9935
Bind long-term conditions (like "in a meeting") to enter/exit
zen mode automatically.
Persist automatic condition subscriptions to maintain them across
reboots.
Normalize condition state binding: true => enter zen, false => exit.
Change-Id: Icba2b8b25c0a352ae8215f4c0a324e4f966c0165
- Fix regression with alarms.
- Run all condition provider callbacks on the main thread.
- Exit zen mode if the current condition is disabled / uninstalled.
Bug:14402762
Change-Id: I0746670c1910047a9dc9b7e29aa1a6c3899fd9fe
On the app side, requests are now composed by subclassing
from various types of Request objects.
On the service side, starting a voice interaction session
involves starting another service that will then manage the
session. This leads the service design much more to what
we want, where the long-running main service is very tiny
and all the heavy-weight transient session work is elsewhere
in another process.
Change-Id: I46c074c6fe27b6c1cf2583c6d216aed1de2f1143
Add the condition provider interface, base class, and associated
system metadata.
Pull out common service management code into a reusable helper,
used by notification listeners and condition providers. The
helper, ManagedServices, is now completely self-contained - it
has no dependencies on NoMan or NoMan abstractions.
Bug:13743109
Change-Id: I6856d40f0a2ead78ac9b5707568559a57e7eb009
This gives a basic working implementation of a persist
running service that can start a voice interaction when
it wants, with the target activity(s) able to go through
the protocol to interact with it. It may even work when
the screen is off by putting the activity manager in the
correct state to act like the screen is on.
Includes a sample app that is a voice interation service
and also has an activity it can launch.
Now that I have this initial implementation, I think I
want to rework some aspects of the API.
Change-Id: I7646d0af8fb4ac768c63a18fe3de43f8091f60e9
Load and store user configuration for do not disturb. Separate
out service-related aspects into new helper. Make config availble
over NoMan for settings.
Implement phone + message based filtering (package whitelist for now).
Implement automatic enter/exit zen mode overnight scheduler.
Bug:14211946
Change-Id: Ib28aab0e4c5c9a5fd0b950b2884b1ab618fdfeca
Declare a new method, Display.getState() to retrieve the actual
power state of a display.
Improved documentation for Intent.ACTION_SCREEN_ON and
Intent.ACTION_SCREEN_OFF to clarify what they really mean in
terms of the interactive state of the device.
Deprecated PowerManager.isScreenOn() and replaced it with
PowerManager.isInteractive() with a more suggestive name and
better documentation.
Redirect display power state changes to go through the display
manager first and only then head over to the power manager for
legacy compatibility.
Eliminated the bright here and woke here policy flags since they
were unused. Simplified the input dispatch policy somewhat.
Ensure that screen wake locks are respected up until the point
when dozing really begins.
Fixed a regression in DreamService where onDreamingStarted
might be called before onWindowAttached.
Bug: 13133142
Bug: 13472578
Bug: 13929355
Bug: 13760290
Change-Id: Iabef96921dd554ce3768fb18619cefc3230b5fb0
For Listeners built against L or greater
Send notifications from related users to listeners.
Return notifications from related users getAllActiveNotifications
Cancel notifications from related users in cancelAllNotifications
Deprecate StatusBarNotification.getUserId() and expose getUser()
as APIs should use UserHandles.
Deprecate cancelNotification that takes package, id and tag
in favour of one that takes key.
Fix bug that notifications from related users didn't
trigger sounds.
Change-Id: I1b1c20c9f305b8f3c4047bc5720d8e99cdedfe70
Instead of posting onDreamingStarted() to a handler from attach(), do
the work immediately. This ensures that the dream is actually in the
expected state when the callback runs. Previously it was possible
for the callback to run after detach() occurred which could cause
exceptions and unexpected behavior. As it happens, there's no need
to post this callback since attach() already runs on the UI thread.
Handle certain races involving the window token lifecycle a little
better. When the dream manager shuts down a dream, it removes the
window token. This can happen before the dream completes its attach()
phase in which case a BadTokenException is thrown. We now handle this
exception and abort the dream in anticipation of receiving a request
to finish it immediately.
Add a safeguard to getDozeHardware() to handle the case where it
might inadvertently be called at the wrong point in the lifecycle.
Bug: 13475612
Bug: 13760290
Change-Id: I9bc9c154370d08d7727b568d398c460a38592099
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
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.
Change-Id: I512e758f3c3ffd3b353dba3b911c0e80a88d6f5f
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
Check explicitly for null listeners in NMS, throwing
IllegalArgumentException (on the small list of exceptions
that survive RPC boundaries) with a message.
Normally this situation is caused by listeners that attempt to
perform NM-related actions before they are bound. Check for
this case in the base NLS class and avoid the call to NM if we
know it will fail.
Although it's tempting to throw an IllegalStateException on the
client side, preserve the existing semantics for backwards-compatibility
purposes. That is, silently fail (or return null) - and provide a
log warning.
Bug:12805707
Change-Id: I0d92fd0d460a8592e8a23fd8fd718ae2ba3bd4c7
Check explicitly for null listeners in NMS, throwing
IllegalArgumentException (on the small list of exceptions
that survive RPC boundaries) with a message.
Normally this situation is caused by listeners that attempt to
perform NM-related actions before they are bound. Check for
this case in the base NLS class and avoid the call to NM if we
know it will fail.
Although it's tempting to throw an IllegalStateException on the
client side, preserve the existing semantics for backwards-compatibility
purposes. That is, silently fail (or return null) - and provide a
log warning.
Bug:12805707
Change-Id: I0d92fd0d460a8592e8a23fd8fd718ae2ba3bd4c7
turns out, without parameters, javadoc will link to the best matching
method signature, even if it's from the superclass. So these were pointing
to Object.nofify()
Change-Id: I13688f2b65e898d1f000a34c88d0aaed928884b5
- Wrap all public member variables in getters and make
slots private
- Rename clear* methods to cancel* to be more consistent
with existing public Notification API
Bug: 8656860
Change-Id: I84f7e71fbb627f859352a93089c6a531b44dac95
This allows a listener service to catch up on the current
state of the notification panel at any time, including at
startup.
Bug: 8656860
Change-Id: I1a3d665d84576e17870929a63dda334afc696010
Protip: Don't mess with Bundles after you've sent them off
for parceling in an RPC.
Note that this change reduces the payload size of
StatusBarNotification objects received in
onNotificationRemoved() callbacks; it scrubs out the
RemoteViews and Bitmaps just as the NoMan's internal archive
does. [You don't really need that information anyway when
hearing about a removed notification; most likely all you
need are the other slots on StatusBarNotification, but
nulling the whole Notification object breaks a lot of
clients.]
Bug: 8616295
Change-Id: Ic899045f2352b96dcf064d3e9e51dad52629aea3
Redesigned how ViewRootImpl delivers input events to views,
the IME and to native activities to fix several issues.
The prior change to make IME input event delegation use
InputChannels failed to take into account that InputMethodManager
is a singleton attached to the main looper whereas UI may be
attached to any looper. Consequently interactions with the
InputChannel might occur on the wrong thread. Fixed this
problem by checking the current thread and posting input
events or callbacks to the correct looper when necessary.
NativeActivity has also been broken for a while because the
default event handling logic for joysticks and touch navigation
was unable to dispatch events back into the native activity.
In particular, this meant that DPad synthesis from touch navigation
would not work in any native activity. The plan is to fix
this problem by passing all events through ViewRootImpl as usual
then forwarding them to native activity as needed. This should
greatly simplify IME pre-dispatch and system key handling
and make everything more robust overall.
Fixed issues related to when input events are synthesized.
In particular, added a more robust mechanism to ensure that
synthetic events are canceled appropriately when we discover
that events are no longer being resynthesized (because the
application or IME is handling or dropping them).
The new design is structured as a pipeline with a chain of
responsibility consisting of InputStage objects. Each InputStage
is responsible for some part of handling each input event
such as dispatching to the view hierarchy or to the IME.
As a stage processes an input event, it has the option of
finishing the event, forwarding the event to the next stage
or handling the event asynchronously. Some queueing logic
takes care to ensure that events are forwarded downstream in
the correct order even if they are handled out of order
by a given stage.
Cleaned up the InputMethodManager singleton initialization logic
to make it clearer that it must be attached to the main looper.
We don't actually need to pass this looper around.
Deleted the LatencyTimer class since no one uses it and we have
better ways of measuring latency these days using systrace.
Added a hidden helper to Looper to determine whether the current
thread is the indicated Looper thread.
Note: NativeActivity's IME dispatch is broken by this patch.
This will be fixed later in another patch.
Bug: 8473020
Change-Id: Iac2a1277545195a7a0137bbbdf04514c29165c60
This is the best and only way for apps to listen for
notifications: create a NotificationListenerService, wait
for the NoMan to bind to you (as a result of the user
checking a box somewhere in Settings and agreeing to a
scary dialog box), and you'll start receiving notification
posted and dismissed callbacks. Your service, while enabled,
will also be able to clear one or all notifications.
Use this power wisely.
This change moves StatusBarNotification out of
com.android.internal into android.service.notification.
[Internal customers, including System UI and early users of
the system-only listener binder API, will need to be
updated.]
Bug: 8199624
Change-Id: I1be46f823d4b3ddc901109ec1e085cd6deb740c2
The window manager now maintains and reports a new formal
"overscan insets" for each window, much like the existing
content and visible insets. This is used to correctly
position the various UI elements in the various combination
of layout options. In particular, this allows us to have
an activity that is using fitSystemWindows to have the content
of its UI extend out to the visible content part of the screen
while still positioning its fixed UI elements inside the
standard content rect (and the entire window extending all
the way into the overscan area to fill the screen as desired).
Okay, maybe that is not written so clearly. Well, it made
my head hurt too, so suffer!
The key thing is that windows now need to know about three
rectangles: the overall rectangle of the window, the rectangle
inside of the overscan area, and the rectangle inside of the
content area. The FLAG_LAYOUT_IN_OVERSCAN option controls
whether the second rectangle is pushed out to fill the entire
overscan area.
Also did some improvements to debug dumping in the window
manager.
Change-Id: Ib2368c4aff5709d00662c799507c37b6826929fd
