Ensure that, in the preflight permission check, RecognitionService does
not check the service's own permissions. These will be checked if the
RecognitionService tries to access the mic
Fixes: 193111794
Test: manual
Change-Id: I172849f2e0368f9601dc298e6cf96d7a52219e5a
This change allows to test on-device listening via a temporary
recognizer even in devices that do no support on device recognition.
It moves the failure from the static
SpeechRecognizer#createOnDeviceSpeechRecognizer to the instance #startListening.
fail-on-listening
Bug: 192586674
Test: atest CtsVoiceRecognitionTestCases with both config and no config
Change-Id: Id722f4e5167132b76b4fbd5ea0c2ef7d19f15909
Only create the callback (and call onCancel) if the preflight permission
check succeeds.
Bug: 190848702
Test: manual
Change-Id: Ie7155348213e86dea0a9080a9c4ed53144f91c6f
This ensures that, when platform checks fail, the RecognitionService is
notified that it should cancel recognition
Fixes: 190848702
Test: manual
Change-Id: I5073728e544a47f386824ca0a034e149661d864a
SpeechRecognizer#createSpeechRecognizer(Context, ComponentName) should
be called only with ComponentNames that are actually mapped in the
running environment.
This update documents how to check the ComponentName is acutally mapped
to RecognitionService.
Bug: 187176179
Test: n/a javadoc change only
Change-Id: Icbf1595f613d6f341b84879122e5eefce6c0fb4a
Attribution source is the abstraction to capture the data
flows for private data across apps. Checking permissions
for an attribution source does this for all apps in the
chain that would receive the data as well as the relevant
app ops are checked/noted/started as needed.
Teach speech recognition service about attribution
chains. If an implementation does nothing the OS
would enforce permisisons and do blame as always.
This apporach leads to double blaming and doesn't
support attribition chains where app calls into
the default recognizer which calls into the on
device recognizer (this nests recursively). If the
implementer takes advantage of the attribution chain
mechanims the permissions for the entire chain are
checked at mic access time and all apps are blamed
only once.
Fixed a few bugs around finishing ops for attribution
chains. Also ensured that any app death in a started
attribution chain would lead to finishing the op for
this app
bug: 158792096
Test: (added tests for speech reco)
atest CtsMediaTestCases
atest CtsPermissionTestCases
atest CtsPermission2TestCases
atest CtsPermission3TestCases
atest CtsPermission4TestCases
atest CtsPermission5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Merged-In: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
Change-Id: Ic92c7adc14bd2d135ac13b96f17a1b393dd562e4
ag/14530956 broke presubmit (b/188784537) because
CtsVoiceRecognitionTestCases did not run.
This makes them run for any change to core/java/android/speech
Bug: 188784537
Test: presubmitting this CL
Change-Id: I9e65abad8d242e5bb87fabc3523909bb14eed3c1
I've deleted the extra attribution for now just to fix the bug asap, but
we need a long-term sync to make sure attribution works properly. For
both cases when the RS app decides to integrate with the new attribution
framework OR decides to ignore it.
Bug: 184963112
Test: atest CtsVoiceRecognitionTestCases
Change-Id: I20bd8174c1a188da6c5af55cdd3bebee8a638d2d
Add a constant to signify that the caller of a RecognitionService has
opened an audio stream for the service
Bug: 185936177
Test: build
Change-Id: Id8da84714fef547d2143457c2ad1c0b631e40741
Additionally, address minor feedback from API council regarding errors
and documentation.
Test: N/A, adding constants
Bug: 176578753
Bug: 183427999
Change-Id: I46358373e8d562cb829ff44232252d26bb5acda4
This CL fixes client listener notification upon engine binding error.
In addition fixes logs verbosity for errors caused by calls on dead client.
Bug: 183085464
Test: atest CtsSpeechTestCases
Change-Id: Ic67e97befd87f841430a53993ae5c79d81a0f6ba
When an app is proxying access to runtime permission protected
data it needs to check whether the calling app has a permission
to the data it is about to proxy which leaves a trace in app ops
that the requesting app perofmed a data access. However, then the
app doing the work needs to get the protected data itself from the
OS which access gets attributed only to itself. As a result there
are two data accesses in app ops where only the first one is a
proxy one that app A got access to Foo through app B - that is the
one we want to show in the permission tracking UIs - and one
for the data access - that is the one we would want to blame on
the calling app, and in fact, these two accesses should be one -
that app A accessed Foo though B. This limitation requires fragile
one off workarounds where both accesses use the same attribution
tag and sys UI has hardcoded rules to dedupe. Since this is not
documented we cannot expect that the ecosystem would reliably
do this workaround in apps that that the workaround in the OS
would be respected by every OEM.
This change adds a mechaism to resolve this issue. It allows for
an app to create an attribution context for another app and then
any private data access thorugh this context would result in a
single app op blame that A accessed Foo though B, i.e. we no longer
have double accounting. Also this can be nested through apps, e.g.
app A asks app B which asks app C for contacts. In this case app
B creates an attribution context for app A and calls into app C
which creates an attribution context for app B. When app C gets
contacts the entire attribution chain would get a porper, single
blame: that C accessed the data, that B got the data from C, and
that A got the data form B. Furthermore, this mechanism ensures
that apps cannot forget to check permissions for the caller
before proxying private data. In our example B and C don't need
to check the permisisons for A and B, respectively, since the
permisisons for the entire attribution chain are checked before
data delivery. Attribution chains are not forgeable preventing
a bad actor to create an arbitrary one - each attribution is
created by the app it refers to and points to a chain of
attributions created by their corresponding apps.
This change also fixes a bug where all content provider accesses
were double counted in app ops due to double noting. While at
this it also fixes that apps can now access their own last ops.
There was a bug where one could not pass null getting the attributed
ops from a historical package ops while this is a valid use case
since if there is no attribution everything is mapped to the null
tag. There were some app op APIs not being piped thorough the app
ops delegate and by extension through the app ops policy. Also
now that we have nice way to express the permission chain in a
call we no longer need the special casing in activity manager to
handle content provider accesses through the OS. Fixed a bug
where we don't properly handle the android.os.shell calls with
an invlaid tag which was failing while the shell can do any tag.
Finally, to ensure the mechanims is validated and works end-to-end
we are adding support for a voice recognizer to blame the client
app for the mic access. The recognition service can create a blaming
context when opening the mic and if the mic is open, which would
do all permission checks, we would not do so again. Since changes
to PermissionChercker for handling attribution sources were made
the CL also hooks up renounced permissoins in the request permission
flow and in the permission checks.
bug:158792096
bug:180647319
Test:atest CtsPermissionsTestCases
atest CtsPermissions2TestCases
atest CtsPermissions3TestCases
atest CtsPermissions4TestCases
atest CtsPermissions5TestCases
atest CtsAppOpsTestCases
atest CtsAppOps2TestCases
Change-Id: Ib04585515d3dc3956966005ae9d94955b2f3ee08
temporarily.
I had to define a new permission in order for it to work (which makes
sense, since we only want to allow shell to overwrite the temp service).
Test: adding CTS
Bug: 177915986
Change-Id: I3ac8f2366595f502b42c9ad93b331d0c0039d16c
This change includes the new System Service that allows the supervised binding to the TextToSpeech service provider.
It proxies the binding process from the client instead of the direct client -> texttospeech connection.
Bug: 178112052
Test: atest CtsSpeechTestCases
Test: forest apct/device_boot_health_check
Change-Id: I0709e71460fa01ab025c92753a20bce38f562845
Revert "Add CTS tests for TextToSpeech connection related functi..."
Revert submission 13547465-ttsproxy
Reason for revert: Setup wizard crashes due to "Service not registered: android.speech.tts.TextToSpeech$SystemConnection"
Reverted Changes:
Id4059e460:Add CTS tests for TextToSpeech connection related ...
Ie17800bae:Add a system TextToSpeech implementation that init...
Bug: 180519958
Change-Id: Ie43c485bd4d0f76f8bb0a1dc77d6d85d46ff8377
Test: Locally reverted this change and no longer see the exception in SUW we saw before.
This change includes the new System Service that allows the supervised binding to the TextToSpeech service provider. It proxies the binding process from the client instead of the direct client -> texttospeech connection.
Bug: 178112052
Test: atest CtsSpeechTestCases
Change-Id: Ie17800bae7a84bfd6e63633f5c914ddbe2c29e9d
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
This is a resubmit of ag/12929664 with some APIs excluded that caused
test failures; see bugs 171886397, 171888296, 171864568.
APIs excluded:
Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord;
Landroid/os/Process;->myPpid()I
Landroid/os/SharedMemory;->getFd()I
Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I
Bug: 170729553
Test: Treehugger
Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
Those annotations could be inferred by some tools (like Kotlin), but the
https://checkerframework.org/ doesn't check inherited annotations
complaining about all equals() invocations that get nullable argument.
The change was generated by running
find . -name \*.java | xargs sed -i 's/public boolean equals(Object /public boolean equals(@Nullable Object /'
in the frameworks/base directory and by automatically adding and
formatting required imports if needed. No manual edits.
Bug: 170883422
Test: Annotation change only. Should have not impact.
Exempt-From-Owner-Approval: Mechanical change not specific to any component.
Change-Id: I5eedb571c9d78862115dfdc5dae1cf2a35343580
