Add various java docs.
Switch to CharSequence where appropriate.
Add new request for canceling voice interaction.
Also update test app to follow API changes and be more better.
Change-Id: If27eeba53cf6444660adb7d37ea2ce0557c6c91f
There is now a special theme for voice interaction activities
to use, so they can be a panel that is better intergrated with
the rest of the voice interaction experience. This is still
not completely working, I have some hacks in the demo app to
get it right; I'll fix that in a future change.
Also improve VoiceInteractor to be retained across activity
instances, for things like rotation.
And bump up the number of concurrent broadcasts that are allowed
on non-svelte devices, since they can handle more and this makes
the boot experience better when dispatching BOOT_COMPLETED.
Change-Id: Ie86b5fd09b928da20d645ec2200577dee3e6889d
New window layer that voice interaction service windows
go in to. Includes a new voice-specific content rectangle
that voice activities are placed in to.
Add specific animations for this layer, sliding down from
the top (though this can be customized by the voice interaction
service).
Also add the concept of activities running for voice interaction
services for purposes of adjusting the animation used for them,
again sliding from the top, but not (yet?) customizable by the
voice interaction service.
Change-Id: Ic9e0e8c843c2e2972d6abb4087dce0019326155d
Use ParceledListSlice to send the list of active notifications
from NoMan to NotificationListeners.
This allows us to simplify the API to what it was before
introducing the "String[] key" workaround for dealing with large
numbers of StatusBarNotifications.
While we're at it, rename Ranking.getIndexOfKey to something that
makes more sense.
Bug: 15126927
Change-Id: I02c2087978c6c4ec1198be496c6250a66143ecb3
Added an ordered list of notifications (n.b. a complete ordering).
Added a mechanism for ranking to be updated asynchronously
Added onNotificationRankingUpdate to NotificationListeners
Added an opaque order update object and a convenience comparator that
uses it to sort notifications for listeners
Repurpose scorers to be ranking preprocessors. The preprocessors will
perform heavy-weight validation of the notification object and memoize
the results to improve efficiency of the ranking comparator.
Current internal comparator implements status quo ordering, except
that notes with a valid contact sort to the top of their priority
bucket.
Change-Id: I7244c65944a9657df41fb313b3cb5a52e149709d
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
