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
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
- There are actually four things that control the assist data request:
current app allowed, app ops, disabled context/secure settings, and
requested context. The previous refactor had accidentally removed the
check for the secure settings (user disabled context). This CL adds
back the check for the user disabled context.
- In addition, it tried to simplify the callbacks by merging the requested
context and the disabled context into a single state, but the owners
still expected a callback when a context was requested (even if not
allowed). This change will always ensure a callback in that case.
- Also fix small error where we didn't clear the pending data/screenshot
after processing
Bug: 68759932
Bug: 68762521
Test: com.android.server.am.AssistDataRequesterTest
Test: #testCanNotHandleReceivedData_expectNoCallbacks
Test: #testProcessPendingData
Test: CtsVoiceInteractionTestCases
Test: CtsAssistTestCases
Change-Id: I60e049a6bf835fe726bc1133f2f8c9712bec8626
Signed-off-by: Winson Chung <winsonc@google.com>
The shortcut manager now has a set of additional packages that
have access, which the voice interaction system service feeds in
to.
Bug: 68760723
Test: CtsVoiceInteractionTestCases
Change-Id: I2a69f83569eb350f405bdd548998570ceef9ea7e
so other components (system UI, settings, etc) can use them.
Bug: 68769804
Test: Build & presubmit
Change-Id: I30fe78e49d2187bee7c7aeba735cd9c26fc332a5
- Only the recents component package can launch the overview activity
directly, and if an assist data receiver is provided, then assist data
will be proxied to the caller.
Bug: 67864419
Test: com.android.server.am.RecentTasksTest
Test: com.android.server.am.AssistDataRequesterTest
Test: CtsVoiceInteractionTestCases
Change-Id: Icdd7e6716a84c11e9262ce5453f7d39ae7d8ce77
- This logic will also be used when the recents component is started to
fetch assist data associated with the current activity.
Bug: 67864419
Test: com.android.server.am.AssistDataRequesterTest
Test: CtsVoiceInteractionTestCases
Change-Id: I4cb3c2536a104d7071bc0a1fd6e31dfc2c0ce8d0
...VOICE_RECOGNITION_SERVICE that is needed for SearchSpeechServices
System setup was incorrectly completely runing off
VoiceInteractionManagerService if the associated feature is not set,
but the service needs to always be running, and instead rely on
the existing logic of reducing functionality if it should not be
running full voice interaction services.
Test: manually booted and ran
Bug: 65055576
Change-Id: I9a83216d45689440c71d657ba2721faf0662b0ff
When invoking updateAllRecognitions, if a callback binder was determined
to have died, an internal function would go and remove it from
mModelDataMap. However, updateAllRecognitions was iterating over this
map, so it would then explode. By first making a copy of the model datas
before iterating over all of them, this problem is avoided.
(As part of trying to figure out what was happening, also updated all
the method names that implicitly assumed they had a lock, and double
checked that everything with a Locked suffix is actually locked)
Bug: 62487479
Test: Use the sound trigger test app to load and start two models, force
kill the app (so the dangling binders hang around), then enable power
save (which triggers the call to updateAllRecognitions)
Change-Id: I87b9dfc1b2af5e294050b146737916ccaad882c1
- It is possible for the session to be requested to be hidden before it
gets the message to be shown and completes showing. This leads to an
inconsistency where the voice interaction service implementation will be
in a different state than the system for the session. Instead, we can
cancel any pending show messages, and also clean up the pending show
callback list immediately when the session is hidden.
- Also fixing up some error message codes when starting the assistant
activity.
Bug: 38379130
Test: android.server.cts.ActivityManagerAssistantStackTests
Test: CtsVoiceInteractionTestCases
Test: CtsAlarmClockTestCases
Change-Id: I0d0e9c024367a47bda82d6a29ca89e18b7d69527
When the package that contains the current voice interaction service component
is changed, internal state of VoiceInteractionManagerService needs to
modified to correctly reflect that.
Bug: 36649034
Test: manual
Change-Id: I7e21ac25785b035711affd87f1b04efa717b13c4
This change introduces new methods on DumpUtils that can check if the
caller has DUMP and/or PACKAGE_USAGE_STATS access. It then moves all
existing dump() methods to use these checks so that we emit
consistent error messages.
Test: cts-tradefed run commandAndExit cts-dev -m CtsSecurityTestCases -t android.security.cts.ServicePermissionsTest
Bug: 32806790
Change-Id: Iaff6b9506818ee082b1e169c89ebe1001b3bfeca
If some process tries to start a recognition, the STH will now check to
see if there are any other models that have been loaded and either:
- Have a callback that's died (determined by pinging the binder)
- Don't have a callback at all (meaning they didn't clean up after the
last detection and didn't start it again).
If it finds such a model, it will be stopped and unloaded, freeing up
resources in the HAL.
Test: Manually load model/kill the process and make sure that it is
unloaded the next time some other model is loaded. Also made sure
running models aren't evicted.
Change-Id: Ia1139b47afe5f88102a3773d90f4f056ea3cdc92
If an app has died while being connected to the sound trigger helper/the
binder goes away, we should stop and unload the model since there's no
way to get a handle on it again (without reloading the same UUID at some
point).
Test: Force stop the SoundTriggerTestApp while it has a model started,
trigger the sound model, then watch it get unloaded when the helper
notices that the binder is dead.
Change-Id: Iddfaaa03482d56e71f23e5982d4bd579f386b51d
The BatterySaverPolicy is designed to consolidate all battery saver
knobs into a central location. Usually it is consistent to
mLowPowerModeEnabled unless it gets different data for specific
service. By adding these knobs, we can effectively tune the battery
saver.
This cl sets up the framework for BatterySaverPolicy and updates
following service to get battery saver data from BatterySaverPolicy
1. GnssLocationProvider
2. VibratorService
3. WindowManagerService
4. BackupManagerService
5. SoundTriggerService
6. NetworkPolicyManagerService
Screen brightness will come in a following cl.
Bug: 34693888
Test: FrameworksServicesTests
Change-Id: I6b040e93391614b44d136a485faa4a332c396e51
- Add a new stack that is not resized with multiwindow, and
appears above the fullscreen and docked stacks, but below
the pinned stack
- Add a method on VoiceInteractionSession to allow the assistant
to launch activities into this new fullscreen stack.
- Also prevent any activities in the assist stack from the
fetching of the on screen assist data.
Bug: 30999386
Test: android.server.cts.ActivityManagerAssistantStackTests
Change-Id: I22ab7629b5f758cf1e66d7d1c26648af6bc887c9
Window tokens can now only be on one display, so we now require clients
that want to add/remove window tokens to specify the display they would
like the token to be created on. This simplifies the token handling code
in WM and will be useful moving forward for clients that want to add
windows to external displays.
Test: Existing tests pass
Change-Id: I6b2d8d58a913b3624f1a9a7bebbb99315613f103
The public API for getting at KeyphraseSoundModels is based on the user,
locale, and keyphrase ID. However, the sound model database would allow
multiple models to be registered using the same values, as it has a
primary key on the model UUID. This can potentially lead to a scenario
where multiple models are enrolled for the same user, and the data that
is returned when querying models is arbitrary.
V6 of the sound model database now enforces a primary key over the user
ID, locale and keyphrase ID. When inserting a new model with the same
primary key, the old model will be removed and the new model will be
used instead.
When upgrading from V5 to V6, if there are any models that would violate
the primary key constraint, they are all dropped.
Bug: 32174118
Change-Id: I9597c6a994f01a426625c3be2c53e826f26f5156
...on removing the third pary search app
We weren't taking into account old style assistants when determining
whether something interesting had been removed.
Change-Id: I6b7b09cdf0781622924e10556d678565570dbd05
If the recognition was aborted due to the service state being set to
false, clients were not made aware that the model had been stopped (but
would get a resume event).
Bug: 30233664
Change-Id: I9f663362ff142eadfd5ef727c5f0c941f8e9e89d
