Issue #19912529: VI: VoiceInteractor callback ClassCastException
Fix to use correct argument.
Issue #19912636: VI: Documentation for VoiceInteractionSession.onBackPressed
Added documentation.
Issue #19912703: VI: VoiceInteractionSession NPE on Abort Request
Maybe fix this -- don't crash if there is no active session.
Issue #19953731: VI: Add value index to...
...android.app.VoiceInteractor.PickOptionRequest.Option
There is now an optional index integer that can be associated with
every Option object.
Issue #19912635: VI: Behavior of startActivity when in voice...
...interaction is unexpected
We now forcibly finish the current voice interaction task whenever
another activity takes focus from it.
Issue #20066569: Add API to request heap dumps
New ActivityManager API to set the pss limit to generate heap
dumps.
Also added app ops for assist receiving structure and screenshot
data, so that we can track when it does these things.
Change-Id: I688d4ff8f0bd0b8b9e3390a32375b4bb7875c1a1
New APIs on ViewAssistStructure all the app to request to
build a sub-tree asynchronously and indicate when it is done
with that. The overall AssistStructure is now only flattened
and transfered on-demand, when the app receiving it requests
its data -- and at that point we can wait for any asynchronous
building to complete.
New AsyncStructure view is a very simple example of using this
to asynchronously build a child view.
Change-Id: I14f9199bee64915ad3dc80b2190916ec874308af
Instead of collecting all of the data directly in AssistStructure,
we now have a dispatch mechanism down the hierarchy to do so.
While doing this, also added the ability to automatically collect
assist data from AccessibilityNodeProviders attached to views
(so now we see all of the data in for example Calendar).
This is a first step needed towards being able to asynchronously
populate assist data.
Change-Id: I59ee1ea104ca8207bad8df7a38195d93da1adea7
Add view ID information to the assist structure.
Also rework the API to simplify how it works by removing
the ViewNode wrapper around ViewNodeImpl -- these are now
just the same thing. And then add complexity by introducing
a formal WindowNode object that contains the top-level window
information (so I can add in some more window-specific info
in the future).
Change-Id: I5d525cf61ab6a73193e5cceb4c09d2d21cc27bae
New flag you pass in to startSession() to say you want it,
new callback on VoiceInteractionSession to receive it.
Change-Id: I61fdcfdee41a60d46036a2ef16681a9b4181115a
Also add API for voice interaction service to control
whether the system should hold a wake lock while it is
working with an activity (and actually *do* hold a wake
lock while doing so, duh!).
And while in there, clean up the launching wake lock to
correctly give blame to the app that is launching.
Change-Id: I7cc4d566b80f59fe0a9ac51ae9bbb7188a01f433
Optimize parceling of AssistData (which is now renamed to
AssistStructure) by pooling duplicated class name strings.
Change text associated with a view node to a CharSequence,
so styling information comes along.
Include global text attributes -- size, colors, etc.
Introduce a new AssistContent structure, which allows us
to propagate information about the intent and data the
activity is looking at. This further allows us to propagate
permission grants, so the assistant can dig in to that data.
The default implementation propagates the base intent of an
activity, so if for example you bring up the assistant while
doing a share the assistant itself has the same information
and access that was given to the share activity (so it could
for example share it in another way if it wanted to).
Did some optimization of loading PersistableBundle from xml,
to avoid duplicating hash maps and such.
Changed how we dispatch ACTION_ASSIST to no longer include
the more detailed AssistStructure (and new AssistContent)
data when launching; now the example code that intercepts
that needs to be sure to ask for assist data when it starts
its session. This is more like it will finally be, and allows
us to get to the UI more quickly.
Change-Id: I88420a55761bf48d34ce3013e81bd96a0e087637
We now have a formal concept of the session being shown and
hidden, with it being able to continue running while hidden
as long as there is enough RAM.
This changes the flow that a VoiceInteractionSession will
see: onCreate() is when it is first created, onCreateContentView()
is when its UI first needs to be built, onShow() is called each
time it needs to be shown and has the arguments given when the
show request was made (which has been renamed from startSession to
showSession), and then onHide() will be called when the UI is
no longer shown.
The methods show() and hide() now allow a VoiceInteractionSession
subclass to control when it is shown and hidden, working with the
shown state being maintained by the system.
Change-Id: Ic4a430ec7e8bf76a5441fd0425e2932806170fcc
Can switch from a pure overlay at the top of the screen,
to interactive mode with the voice UI drawing at the bottom
and pushing its target activity up like an IME.
Add mechanism to get assist data to the voice interaction UI.
Add some basic visualization of the assist data, outlining
where on the screen we have text.
Add a test ACTION_ASSIST handler, which can propagate the
assist data it gets to the voice interaction session so
you can see what kind of data we are getting from different
apps.
Change-Id: I18312fe1601d7926d1fb96a817638d60f6263771
- Make Callback an abstract class
- Split manage intents into 3 different methods
- Remove RECOGNITION_FLAGS_NONE
Bug: 17255602
Change-Id: I1329f889bb2ab35938f42d2ecfe755d2b17ec542
Tighten the API by taking in a locale rather than a string tag.
Tighten the checks when reading the enrollment metadata, bail out if any
attribute is missing or invalid.
Add missing recycle call for a TypedArray
Stop recognition when sound model(s) change. This is needed during
un-enrollment/re-enrollment.
Bug: 17187528
Bug: 17205230
Change-Id: Idb00b51ef8c4ea0a8f8993decea582223181fa3d
Internally we pause the recognition when:
- a phone call is active/off-hook/ringing
- or some other application grabs the microphone
we auto-resume when the condition that caused us to pause reverses.
Both these events are notified to the client via callbacks so that they can choose to display on their UI,
that the recognition is paused for some reason.
Bug: 16515468
Bug: 16740806
Bug: 16514535
Change-Id: Ib274d68522c8cf37d42402c875b16159957657f0
Also annotate the flags with @IntDef to make things clearer and safer
Add more debug logging
Revert to start/stop being synchronous since telephony and microphone will
need to be handled internally.
Bug: 16731586
Bug: 16514535
Bug: 16549061
Change-Id: I83695d52e9547269c95d443e4d921c9238b7401e
Don't call back for a detector being marked invalid because
that happens when someone else obtains a detector or VIS shuts down,
in either case we don't want a loop where two entities keep creating new detectors
and being invalidated.
Don't call back on an invalid detector for availability change/detected/started and stopped
only propagate errors.
This helps us with cases where a callback for the previous VIS may get called and then crash because it
tries to make calls without being the current VIS.
In the new scheme of things, if the VIS changes, or the current VIS obtains a new AlwaysOnHotwordDetector,
the previous one is shutdown and internally marked as invalid and all calls to it fail with an IllegalStateException.
Bug: 16629417
Change-Id: I74417bf76ba80916ebc21b042c18b3467857733e
- This is needed for telephony and audio integration which should happen via async callbacks
that'll end up starting/stopping recognition.
e.g. if a startRecognition happens when in a phone call - the onDetectionStarted will get called once the phone
call ends.
For now the transient stoppages due to internal reasons will not be propagated back to the client.
Bug: 16514535
Bug: 16515468
Change-Id: I1b2b8edd28f5c5e67c453f66c23e1a67a626114e
This helps us make the list sound models operation an async one, it also helps us
with the case where a detector is invalidated, so the client doesn't have to keep checking the
state.
Synchronize DatabaseHelper methods on its instance so that other VoiceInteractionManagerService
calls aren't blocked on db writes/reads.
It's still possible for the list operation to be blocked on update and vice-versa
Change-Id: Ib8ec4ac5056b62d443038560ce31d0641b4627b0
Add a callback for when any sound model change happens. This helps the VIS
to re-check the availability and either enroll the user, or start/stop recognition.
Also shut down any active recognition when VIS dies, or a different hotword detector instance is obtained from VIS.
Change-Id: I03f94e78c6ee307afe822a84aebc7e74c64de7b4
- Remove unnecessary recognition status from AlwaysOnHotwordDetector
- Remove unnecessary recognition started callback from IRecognitionStatusCallback
- Fix a bug around the fact that we weren't picking up enrollment at runtime because
we were storing the availability at instantiation time.
- Handle 0-length arrays in SoundTrigger classes while parceling/unparceling
- Fix issue in SoundTrigger helper where we were not comparing binders for start/stop calls
- Unload the previous model when starting a new recognition
- Add more debug logging
Change-Id: Icc56d7f3dd1ffa49a8cfeea49080e3ab4d342c32
...state changes.
Add a new API to tell the activity manager about a new dependency
one process has on another package. Start using it already for
when apps is Context.createPackageContext() to load code from another
app.
Also do some work on getting the monitoring of proc/uid states
in shape so it can be used by unundled code, along with an
AppImportanceMonitor class for doing so.
Some small fixes and additions to VoiceInteractionService.
Improve handling of unaccounted/overcounted battery use so that
they aren't shown to the user unless they are significant.
Change-Id: I22dd79a73f4e70103d3f8964494aebc8a31f971c
Add CompleteVoiceRequest to VoiceInteractor to allow apps to indicate when a voice interaction was successfully completed.
Change-Id: I1481cfe96e9e2495d88a7a4fb62263bdd1e03c54
Add model management API skeleton to VoiceInteractionManagerService
Add an "interactor" for all always-on APIs
- The VoiceInteractionService will get an interactor for the given
keyphrase and locale.
- It can then check the availability and call methods to start and
stop recognition on this interactor.
- Add a common class to deal with SoundTrigger APIs
- Cleanup the keyphrase representation:
We now have separate representations for the keyphrase metadata and
a keyphrase being used for recognition.
This'll also help us to handle custom keyphrases in the
future easily.
This also ensures that for use within the framework,
we rely on the ID of the KeyphraseInfo rather than comparing the
text everytime.
Add a callback for the AlwaysOnHotwordDetector
This callback should be passed in by the VoiceInteractionService and is used to notify it
of recognition events.
Change-Id: I26252298773024f53a10cdd2af4404a4e6d74aae
- Make the enrollment attrs public
- Add a dummy activity for enrollment
- Manually tested that the meta-data is correctly read by the
VoiceInteractionService when the enrollment application is under
/system/priv-app
Change-Id: I36676ed8ffc919109031c26bac047d0c51a77e13
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
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
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
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
