Continuation of ag/6226654; edits made per Svetoslav's last comments.
Bug: 122740752
Bug: 123080754
Test: blueline-userdebug build completes successfully.
Change-Id: I3e43137eb6e0d8cae77e14d331150d5a05ede07c
- Extract current code for checking caller into a private method
- Replace occurrences of that code with a call to the private method
- Add method call to setTranscription/clearTranscription/setVoiceState
Test: Verified Milford can't call setTranscription/clearTranscription
when it is no longer the active service.
Bug: b/123412646
Change-Id: I2c428c6c65b62f6a83264286df4f44fb5d1c249e
events.
This change should have been part of ag/5933708
Test: manual test with NowPlaying app on p19 device
Change-Id: I42ed7c17ebdd2cb75055122b8d45302e28c510b6
- Register a role observer in VoiceInteractionManagerService. Once the
role is changes map the new role setting onto the old settings.
- As the assistant role is now always set, there is no need to have code
in AssistUtil for the case the assistant setting is not set
- Remove old config option for the default assistant. The default
assistant is not configured via the roles config
Bug: 110557011
Test: - Set, unset and swtiched assistant via the settings UI
- for voice interaction service
- for assist activity
- Booted from freshly wiped device and saw assitant to be set to
default
Change-Id: I8596f49c6f6496e8b70cf3236aaa7d7557443a93
Voice state as well as voice transcription can be provided by the
VoiceInteractionService. These get proxied to the AssistManager which
can update the system UI to reflect the state & transcription.
Test: TBD
Bug: 122740752
Bug: 123080754
Change-Id: I79cac1d89fe0123bf25a05d551cb4ef40ae1368e
The top-level framework overlay already says this should (by default) be
skipped if the device is low-ram (leaving the device able to turn it
back on again without committing to a specific voice recognizer at build
time):
<feature name="android.software.voice_recognizers" notLowRam="true" />
The form factor-specific overlay for tablets does override this back to
a state where the feature is always enabled regardless of low-ram:
<feature name="android.software.voice_recognizers" />
But this is probably a mistake as the code before this change ignored
the feature flag anyway in case of a low-ram device, using a hardcoded
check.
Lets Android TVs have voice recognisers working on all devices by
default without needing to set katniss' package as a force override.
Bug: 117630721
Test: flashall ; adb logcat | grep VoiceInteractionService
Change-Id: I7816bebbc363ae0751b097fe1b6cdc2a646b20e0
as regular recogntion events
The application will differentiate between DSP and app triggered
regcognition events.
Test: manual test with STTA and NowPlaying app on p19
Bug: 119386757
Change-Id: I4a3eb4da6ee6be35084fec8aaa3c495423d74033
If you have a legacy assist app (launched through ACTION_ASSIST, not
implementing a VoiceInteractionService) then we kept the Google app
as the current speech recognizer. Thus if you force stopped the
Google app, we saw that as one of the active parts of the interactor
or recognizer and reset all of the state.
Now we handle the "only recognizer" case separately, only resettting
the recognizer state in that case.
Bug: 121104681
Test: manual
Change-Id: Icc007bdf2352548d58be997fae77d9e5aba842f3
Add @GuardedBy for simple functions that require locks and have a name in
one of the frameworks naming styles for locks ("^.*(Locked|LPw|LPr|L[a-zA-Z]|UL|AL|NL)$").
Derived by errorprone.
Bug: 73000847
Test: m
Change-Id: If70bb03313388af34d547efca20fb5115de95bf1
Allows for other services like window manager to call uri grants without
holding AM service lock.
Bug: 80414790
Test: Existing tests pass.
Change-Id: Ie5b4ddb19a2cedff09332dbeb56bcd9292fd18ac
Moved more stuff related to activities out of the current service to the new one.
Bug: 80414790
Fixes: 110988007
Test: Existing tests pass.
Change-Id: Iceed1da8a7441a26d11efebc6d9f692fd053bc7f
One heavy dependence between the current AMS service and activities
is process management which is heavy affected by activities and their
current state. We introduce WindowProcessController and WindowProcessListener
objects as a structured way for the process changes in AM package to
be communicated to the WM package and WindowProcessListner for activity
changes in the WM package to the communicated back to the AM package.
The ProcessRecord object in AM will own the WindowProcessController object
and also implement the WindowProcessListener.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: I9e96e841b0f95e99a597cb4629fa5d2fe45760b6
Moved more stuff related to activities out of the current service to the new one.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: I16863dd977bf09136cc23b0ab3aa197c613879ea
Objects that contain or represent activities like ActivityRecord can
no longer rely on ActivityManagerService as it is going to be in a
different package.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: I7eabc9b80e494367d79ff7452c88ba82ff216bcd
3rd step in unifying the window hierarchy that is currently split
within AM and WM packages. We separate the the internal interface used
to communicate within system server dealing with activities and their
containers (tasks, stack, display) from the rest of AM internal
interface.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: Idad77721c1fe10621b9be5dced42a0a11f0183e5
Second step in unifying the window hierarchy that is currently split
within AM and WM packages. We move some of the API implementation for
activities from ActivityManagerService.java to
ActivityTaskManagerService.java.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: I23dcd924493d8ad1e0b6e3a55386fd72b0146605
First step in unifying the window hierarchy that is currently split
within AM and WM packages. We separate the interfaces and service dealing
with activities and their containers (tasks, stack, display) from the
rest of AM interfaces and services. This will allow us to move the new
interfaces and services to WM when the internal states are cleaned-up.
Test: Existing tests pass
Test: go/wm-smoke-auto
Bug: 80414790
Change-Id: Ide9b3f89123b768cdbd3e3878113c7a8021187f3
Currently we don't have a way of throttling sound trigger events without
upsettings the DSP.
Bug: 78212455, 78310504
Test: Played music while having song detection enabled. Saw songs being
detected
Change-Id: I3494d608f097532f02e6a588e22d9fe2d06048b1
When trottling we need to simulate handling of the event as otherwise
the DSP gets upset and SoundTriggerService and SoundTriggerHelper get
out of sync.
(1) Currently the DSP requires to open and release the AudioRecord if
a event was detected. Hence If we drop and event we need to do the
minimal version of that
(2) If a recognitions is set up with !allowMultipleTriggers the other
parts assume that as soon as one even is handled no further will be
needed. The other parts of the system are not aware of throttling.
Hence even when throttled we have to destroy the service when
!allowMultipleTriggers.
We do this by splitting the ops into three parts.
Setup (always executed): Takes care of problem (2) by checking the flag
and setting the destroy-once-ops-and-handled flag
Execute (not thottled): Send the op to the remote service
Drop (Trottled): Do what is needed if the remote service is not
involved. This handled issue (1)
Test: Caused throttling and saw - AudioRecord started and released
- service connection destroyed
Bug: 78212455
Change-Id: I0ff81a7b38d07db1365be7ecc44e93cf329b32d5
If we skip an operation we used to just return. This lead to the service
staying connected, holding the wakelock and consuming power.
Hence after we skip an operation we need to check if we can disconnect
the service, basically treating skipping an operation similar failing
to execute the operation.
Fixes: 77766977
Test: Detected music via sound trigger service and triggered dropping of
operations
Change-Id: Ia837d628193b3a5c2763f4aae666193d624b6d7f
How that we have the SoundTriggerDetectionService we don't need the
pending intent based mechanism anymore.
Test: Checked that ambient music still detects music
Change-Id: If16c59028b31ff7d2e7f4d7f764460ac948ba946
Fixes: 73829108
It is not clear when the day should start. Further a day might have
25 hours in the case of daylight savings time.
Hence a day in this case is the last 24 hours, not a calendar day.
Keeping track of the time of each operation might waste memory as we
don't need that much precision.
Hence keep track how many operations were performed in the last 24
hours in buckets of hours. If the total count reaches a maximum suppress
any further operations.
The maximum is configurable via global settings. It can be updated
by apps that have the appropriate permissions. Hence if the default
value turns out to be incorrect, it can be adjusted after release.
This does not throttle based on battery state as it is better to
completely unload the sound model to not even have a detection event.
Test: atest SoundTriggerDetectionServiceTests (separate CL)
atest android.provider.SettingsBackupTest
Bug: 73829108
Change-Id: Ied8570b60b61b6a055bd2576d1502c1b36424efa
The service is meant to replace the PendingIntent based API. Once all
users of the PendingIntent based API switched the PendingIntent based API
will be removed.
To have as little as possible impact on the whole SoundTrigger framework
the RemoteSoundTriggerDetectionService class implements the same
interface as the PendingIntent based class. Hence the exising code has
very little change. Further once the old code can be removed the amount
of changed (and added) code is limited.
The RemoteSoundTriggerDetectionService -> SoundTriggerDetectionService
is a vanilla as possible service implementation. The special behaviors
are:
- The system holds a wakelock while service operations are in progress
and the service is bound as foreground. Hence the service can e.g.
listen to the microphone.
- Service operations have a certain amount of time they are allowed to
run. Once every operation is either finished or the the operation
exceeded the allotted time, the system calls onStopOperation for each
still pending operation. This is a similar model as for the commonly
used JobService.
Please note that if the time allowed for an operation is 15s and
op1 was run as 0si, and op1 was run at 5s, the service is allowed to run
until 20s. Hence _both_ onStopOperations will happen at 20s. This is
done for ease of implementation but should not give the service more
power than calling onStopOperation exactly 15s after each operation is
triggered.
- If an operation is done before the allotted time is reached, the
service can declare the operation as finished manually by calling
onOperationFinished. This is a call back into the system, hence a
'client' binder is sent to the service. If the operation is finished
by calling this method onStopOperation will not be called.
- As the service instance might be killed and restored between
operations we add a opaque bundle 'params' to each operations. The users
of the API can use this to send data from the start command to the
operations. It can also just be set to null. The params are not meant to
store changing state in between operations. Such state needs to be
persisted using the regular methods (e.g. write it to disk)
- A service can be used for multiple recognition sessions. Each
recognition is uniquelity defined by its sound model UUID. Hence each
operation gets at least tree arguments: Operation ID, sound mode UUID, params
- As a small optimization the params are cached inside of the service
instance.
The time allowed for each operation is in a @SystemAPI global setting,
so the service can make sure it finishes the operations before they are
stopped. It might take some time to deliver the operations via the
binder, hence it is not recommended to try to use every last ms of
allotted time.
Test: atest SoundTriggerDetectionServiceTest (added in separate CL)
atest android.provider.SettingsBackupTest
Change-Id: I47f813b7a5138a6f24732197813a605d29f85a93
Fixes: 73829108
When sending outbound callbacks on CELL_INFO and CELL_LOCATION, check to
make sure that the user has authorized us and the receiving app to get
information on their location.
Bug: 69637693
Test: manual: telephony testapp
Change-Id: Iacfc894428b11a7ec973567d7a797eedb281355f
Some switchUser callbacks can block ActivityManager thread for 100+ ms.
The work can be done on a worker thread instead.
Test: Manual create/switch to user
Bug: 37579992
Change-Id: I45034fa8c8bdf457bcc3737c8064057fbfaf32f5
- Notify AM whenever the active voice interaction service changes and
dependency on VoiceInteractionManagerService from AM.
Bug: 70616466
Test: android.server.am.ActivityManagerAssistantStackTests
Change-Id: Ifd3dcbf0b6afc7b3e8a1d9d29bacd5b04af2a15d
The callback of the SoundTriggerService using the intent API used to try
and grab the same lock that other calls to the STS were using when they
accessed the SoundTriggerHelper.
This happens because most functions in the STH grab the STH's lock,
including the one that handles the recognition events. The recognition
event callback in the STS would then try to grab the STS lock, while
implicitly holding the STH one.
However, a concurrent call to the STS from outside could first grab the
STS lock, then call into the STH which may need the STH lock, resulting
in a deadlock.
By removing the requirement that the STS callback grab the main STS
lock, this condition is avoided.
Bug: 70346433
Test: On device
Change-Id: I44571fba786a82a17423d45f503be9537b476a01
...activity launch delays.
Activity manager now has a new private mechanism for other services
to report which apps are allowed to bypass the launch delay restriction,
which voice interaction service uses.
Test: manual
Bug: 68002319
Change-Id: I44e9b67411b5106b81e8363dc22d4e54caeb83c1
