2009-03-03 19:31:44 -08:00
|
|
|
/*
|
2009-10-22 08:36:42 +09:00
|
|
|
* Copyright (C) 2009 The Android Open Source Project
|
2009-03-03 19:31:44 -08:00
|
|
|
*
|
|
|
|
* Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
* you may not use this file except in compliance with the License.
|
|
|
|
* You may obtain a copy of the License at
|
|
|
|
*
|
|
|
|
* http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
*
|
|
|
|
* Unless required by applicable law or agreed to in writing, software
|
|
|
|
* distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
* See the License for the specific language governing permissions and
|
|
|
|
* limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
package android.test.mock;
|
|
|
|
|
2019-05-20 14:00:17 -06:00
|
|
|
import android.annotation.NonNull;
|
2016-12-02 11:35:35 -08:00
|
|
|
import android.annotation.Nullable;
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
import android.content.AttributionSource;
|
2009-10-22 08:36:42 +09:00
|
|
|
import android.content.ContentProvider;
|
|
|
|
import android.content.ContentProviderOperation;
|
|
|
|
import android.content.ContentProviderResult;
|
2020-01-16 17:00:02 -08:00
|
|
|
import android.content.ContentResolver;
|
2009-03-03 19:31:44 -08:00
|
|
|
import android.content.ContentValues;
|
2009-10-22 08:36:42 +09:00
|
|
|
import android.content.Context;
|
|
|
|
import android.content.IContentProvider;
|
2019-05-20 14:00:17 -06:00
|
|
|
import android.content.Intent;
|
2009-05-15 15:10:40 -07:00
|
|
|
import android.content.OperationApplicationException;
|
2009-10-22 08:36:42 +09:00
|
|
|
import android.content.pm.PathPermission;
|
|
|
|
import android.content.pm.ProviderInfo;
|
2009-03-03 19:31:44 -08:00
|
|
|
import android.content.res.AssetFileDescriptor;
|
|
|
|
import android.database.Cursor;
|
|
|
|
import android.net.Uri;
|
2020-01-16 17:00:02 -08:00
|
|
|
import android.os.AsyncTask;
|
2020-05-29 10:51:18 +09:00
|
|
|
import android.os.Binder;
|
2010-03-04 17:48:13 -08:00
|
|
|
import android.os.Bundle;
|
2009-03-03 19:31:44 -08:00
|
|
|
import android.os.IBinder;
|
2012-05-07 20:06:46 -07:00
|
|
|
import android.os.ICancellationSignal;
|
2009-03-03 19:31:44 -08:00
|
|
|
import android.os.ParcelFileDescriptor;
|
2020-01-16 17:00:02 -08:00
|
|
|
import android.os.RemoteCallback;
|
2009-10-22 08:36:42 +09:00
|
|
|
import android.os.RemoteException;
|
2009-03-03 19:31:44 -08:00
|
|
|
|
|
|
|
import java.io.FileNotFoundException;
|
2009-05-22 14:23:31 -07:00
|
|
|
import java.util.ArrayList;
|
2009-03-03 19:31:44 -08:00
|
|
|
|
|
|
|
/**
|
2009-10-22 08:36:42 +09:00
|
|
|
* Mock implementation of ContentProvider. All methods are non-functional and throw
|
|
|
|
* {@link java.lang.UnsupportedOperationException}. Tests can extend this class to
|
2009-03-03 19:31:44 -08:00
|
|
|
* implement behavior needed for tests.
|
|
|
|
*/
|
2009-10-22 08:36:42 +09:00
|
|
|
public class MockContentProvider extends ContentProvider {
|
|
|
|
/*
|
|
|
|
* Note: if you add methods to ContentProvider, you must add similar methods to
|
|
|
|
* MockContentProvider.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* IContentProvider that directs all calls to this MockContentProvider.
|
|
|
|
*/
|
|
|
|
private class InversionIContentProvider implements IContentProvider {
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public ContentProviderResult[] applyBatch(@NonNull AttributionSource attributionSource,
|
|
|
|
String authority, ArrayList<ContentProviderOperation> operations)
|
2009-10-22 08:36:42 +09:00
|
|
|
throws RemoteException, OperationApplicationException {
|
2018-12-07 12:00:45 -07:00
|
|
|
return MockContentProvider.this.applyBatch(authority, operations);
|
2009-10-22 08:36:42 +09:00
|
|
|
}
|
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public int bulkInsert(@NonNull AttributionSource attributionSource, Uri url,
|
2019-09-27 08:44:12 -07:00
|
|
|
ContentValues[] initialValues) throws RemoteException {
|
2009-10-22 08:36:42 +09:00
|
|
|
return MockContentProvider.this.bulkInsert(url, initialValues);
|
|
|
|
}
|
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public int delete(@NonNull AttributionSource attributionSource, Uri url,
|
2019-11-15 12:45:15 -07:00
|
|
|
Bundle extras) throws RemoteException {
|
|
|
|
return MockContentProvider.this.delete(url, extras);
|
2009-10-22 08:36:42 +09:00
|
|
|
}
|
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
2009-10-22 08:36:42 +09:00
|
|
|
public String getType(Uri url) throws RemoteException {
|
|
|
|
return MockContentProvider.this.getType(url);
|
|
|
|
}
|
|
|
|
|
2020-01-16 17:00:02 -08:00
|
|
|
@Override
|
|
|
|
public void getTypeAsync(Uri uri, RemoteCallback callback) throws RemoteException {
|
|
|
|
MockContentProvider.this.getTypeAsync(uri, callback);
|
|
|
|
}
|
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public Uri insert(@NonNull AttributionSource attributionSource, Uri url,
|
2019-11-15 12:45:15 -07:00
|
|
|
ContentValues initialValues, Bundle extras) throws RemoteException {
|
|
|
|
return MockContentProvider.this.insert(url, initialValues, extras);
|
2009-10-22 08:36:42 +09:00
|
|
|
}
|
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public AssetFileDescriptor openAssetFile(@NonNull AttributionSource attributionSource,
|
|
|
|
Uri url, String mode, ICancellationSignal signal)
|
2013-01-14 17:38:02 -08:00
|
|
|
throws RemoteException, FileNotFoundException {
|
2009-10-22 08:36:42 +09:00
|
|
|
return MockContentProvider.this.openAssetFile(url, mode);
|
|
|
|
}
|
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public ParcelFileDescriptor openFile(@NonNull AttributionSource attributionSource,
|
|
|
|
Uri url, String mode, ICancellationSignal signal)
|
2019-09-27 08:44:12 -07:00
|
|
|
throws RemoteException, FileNotFoundException {
|
2009-10-22 08:36:42 +09:00
|
|
|
return MockContentProvider.this.openFile(url, mode);
|
|
|
|
}
|
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public Cursor query(@NonNull AttributionSource attributionSource, Uri url,
|
2019-09-27 08:44:12 -07:00
|
|
|
@Nullable String[] projection, @Nullable Bundle queryArgs,
|
|
|
|
@Nullable ICancellationSignal cancellationSignal) throws RemoteException {
|
2016-12-02 11:35:35 -08:00
|
|
|
return MockContentProvider.this.query(url, projection, queryArgs, null);
|
2009-10-22 08:36:42 +09:00
|
|
|
}
|
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public int update(@NonNull AttributionSource attributionSource, Uri url,
|
2019-11-15 12:45:15 -07:00
|
|
|
ContentValues values, Bundle extras) throws RemoteException {
|
|
|
|
return MockContentProvider.this.update(url, values, extras);
|
2009-10-22 08:36:42 +09:00
|
|
|
}
|
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public Bundle call(@NonNull AttributionSource attributionSource, String authority,
|
2019-09-27 08:44:12 -07:00
|
|
|
String method, String request, Bundle args) throws RemoteException {
|
2018-12-07 12:00:45 -07:00
|
|
|
return MockContentProvider.this.call(authority, method, request, args);
|
2010-03-04 17:48:13 -08:00
|
|
|
}
|
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
2009-10-22 08:36:42 +09:00
|
|
|
public IBinder asBinder() {
|
2018-12-16 15:52:33 -08:00
|
|
|
return MockContentProvider.this.getIContentProviderBinder();
|
2009-10-22 08:36:42 +09:00
|
|
|
}
|
2009-03-03 19:31:44 -08:00
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
Add new ContentProvider for doing conversions to data streams.
This introduces basic infrastructure that should allow content
providers holding complex data to perform on-demand conversion
of their data to streams of various types. It is achieved through
two new content provider APIs, one to interrogate the possible
stream MIME types the provider can return, and the other to
request a stream of data in a particular MIME type.
Because implementations of this will often need to do on-demand
data conversion, there is also a utility intoduced in ContentProvider
for subclasses to easily run a function to write data into a
pipe that is read by the client.
This feature is mostly intended for cut and paste and drag and
drop, as the complex data interchange allowing the source and
destination to negotiate data types and copy (possible large)
data between them. However because it is fundamental facility
of ContentProvider, it can be used in other places, such as for
more advanced GET_CONTENT data exchanges.
An example implementation of this would be in ContactsProvider,
which can now provider a data stream when a client opens certain
pieces of it data, to return data as flat text, a vcard, or other
format.
Change-Id: I58627ea4ed359aa7cf2c66274adb18306c209cb2
2010-08-06 12:16:55 -07:00
|
|
|
public String[] getStreamTypes(Uri url, String mimeTypeFilter) throws RemoteException {
|
|
|
|
return MockContentProvider.this.getStreamTypes(url, mimeTypeFilter);
|
|
|
|
}
|
|
|
|
|
2011-10-09 12:39:53 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public AssetFileDescriptor openTypedAssetFile(
|
|
|
|
@NonNull AttributionSource attributionSource, Uri url, String mimeType,
|
|
|
|
Bundle opts, ICancellationSignal signal)
|
|
|
|
throws RemoteException, FileNotFoundException {
|
Add new ContentProvider for doing conversions to data streams.
This introduces basic infrastructure that should allow content
providers holding complex data to perform on-demand conversion
of their data to streams of various types. It is achieved through
two new content provider APIs, one to interrogate the possible
stream MIME types the provider can return, and the other to
request a stream of data in a particular MIME type.
Because implementations of this will often need to do on-demand
data conversion, there is also a utility intoduced in ContentProvider
for subclasses to easily run a function to write data into a
pipe that is read by the client.
This feature is mostly intended for cut and paste and drag and
drop, as the complex data interchange allowing the source and
destination to negotiate data types and copy (possible large)
data between them. However because it is fundamental facility
of ContentProvider, it can be used in other places, such as for
more advanced GET_CONTENT data exchanges.
An example implementation of this would be in ContactsProvider,
which can now provider a data stream when a client opens certain
pieces of it data, to return data as flat text, a vcard, or other
format.
Change-Id: I58627ea4ed359aa7cf2c66274adb18306c209cb2
2010-08-06 12:16:55 -07:00
|
|
|
return MockContentProvider.this.openTypedAssetFile(url, mimeType, opts);
|
|
|
|
}
|
2012-01-25 19:37:13 -08:00
|
|
|
|
|
|
|
@Override
|
2012-02-02 17:05:00 -08:00
|
|
|
public ICancellationSignal createCancellationSignal() throws RemoteException {
|
2012-01-25 19:37:13 -08:00
|
|
|
return null;
|
|
|
|
}
|
2013-09-06 16:17:22 -07:00
|
|
|
|
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public Uri canonicalize(@NonNull AttributionSource attributionSource, Uri uri)
|
2019-09-27 08:44:12 -07:00
|
|
|
throws RemoteException {
|
2013-09-06 16:17:22 -07:00
|
|
|
return MockContentProvider.this.canonicalize(uri);
|
|
|
|
}
|
|
|
|
|
2020-02-14 17:04:13 -08:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public void canonicalizeAsync(@NonNull AttributionSource attributionSource, Uri uri,
|
2020-02-14 17:04:13 -08:00
|
|
|
RemoteCallback callback) {
|
|
|
|
MockContentProvider.this.canonicalizeAsync(uri, callback);
|
|
|
|
}
|
|
|
|
|
2013-09-06 16:17:22 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public Uri uncanonicalize(@NonNull AttributionSource attributionSource, Uri uri)
|
2019-09-27 08:44:12 -07:00
|
|
|
throws RemoteException {
|
2013-09-06 16:17:22 -07:00
|
|
|
return MockContentProvider.this.uncanonicalize(uri);
|
|
|
|
}
|
2016-11-10 13:50:54 -08:00
|
|
|
|
2020-10-23 15:47:19 -07:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public void uncanonicalizeAsync(@NonNull AttributionSource attributionSource, Uri uri,
|
2020-10-23 15:47:19 -07:00
|
|
|
RemoteCallback callback) {
|
|
|
|
MockContentProvider.this.uncanonicalizeAsync(uri, callback);
|
|
|
|
}
|
|
|
|
|
2016-11-10 13:50:54 -08:00
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public boolean refresh(@NonNull AttributionSource attributionSource, Uri url,
|
2019-09-27 08:44:12 -07:00
|
|
|
Bundle args, ICancellationSignal cancellationSignal) throws RemoteException {
|
2016-11-10 13:50:54 -08:00
|
|
|
return MockContentProvider.this.refresh(url, args);
|
|
|
|
}
|
2019-05-20 14:00:17 -06:00
|
|
|
|
|
|
|
@Override
|
Runtime permission attribution improvements
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
2021-02-24 04:09:05 +00:00
|
|
|
public int checkUriPermission(@NonNull AttributionSource attributionSource, Uri uri,
|
2019-09-27 08:44:12 -07:00
|
|
|
int uid, int modeFlags) {
|
2019-05-20 14:00:17 -06:00
|
|
|
return MockContentProvider.this.checkUriPermission(uri, uid, modeFlags);
|
|
|
|
}
|
2009-03-03 19:31:44 -08:00
|
|
|
}
|
2009-10-22 08:36:42 +09:00
|
|
|
private final InversionIContentProvider mIContentProvider = new InversionIContentProvider();
|
2009-03-03 19:31:44 -08:00
|
|
|
|
2009-10-22 08:36:42 +09:00
|
|
|
/**
|
|
|
|
* A constructor using {@link MockContext} instance as a Context in it.
|
|
|
|
*/
|
|
|
|
protected MockContentProvider() {
|
|
|
|
super(new MockContext(), "", "", null);
|
2009-03-03 19:31:44 -08:00
|
|
|
}
|
|
|
|
|
2009-10-22 08:36:42 +09:00
|
|
|
/**
|
|
|
|
* A constructor accepting a Context instance, which is supposed to be the subclasss of
|
|
|
|
* {@link MockContext}.
|
|
|
|
*/
|
|
|
|
public MockContentProvider(Context context) {
|
|
|
|
super(context, "", "", null);
|
2009-03-03 19:31:44 -08:00
|
|
|
}
|
|
|
|
|
2009-10-22 08:36:42 +09:00
|
|
|
/**
|
|
|
|
* A constructor which initialize four member variables which
|
|
|
|
* {@link android.content.ContentProvider} have internally.
|
|
|
|
*
|
|
|
|
* @param context A Context object which should be some mock instance (like the
|
|
|
|
* instance of {@link android.test.mock.MockContext}).
|
|
|
|
* @param readPermission The read permision you want this instance should have in the
|
|
|
|
* test, which is available via {@link #getReadPermission()}.
|
|
|
|
* @param writePermission The write permission you want this instance should have
|
|
|
|
* in the test, which is available via {@link #getWritePermission()}.
|
|
|
|
* @param pathPermissions The PathPermissions you want this instance should have
|
|
|
|
* in the test, which is available via {@link #getPathPermissions()}.
|
|
|
|
*/
|
|
|
|
public MockContentProvider(Context context,
|
|
|
|
String readPermission,
|
|
|
|
String writePermission,
|
|
|
|
PathPermission[] pathPermissions) {
|
|
|
|
super(context, readPermission, writePermission, pathPermissions);
|
|
|
|
}
|
|
|
|
|
|
|
|
@Override
|
|
|
|
public int delete(Uri uri, String selection, String[] selectionArgs) {
|
2009-03-03 19:31:44 -08:00
|
|
|
throw new UnsupportedOperationException("unimplemented mock method");
|
|
|
|
}
|
|
|
|
|
2009-10-22 08:36:42 +09:00
|
|
|
@Override
|
|
|
|
public String getType(Uri uri) {
|
2009-03-03 19:31:44 -08:00
|
|
|
throw new UnsupportedOperationException("unimplemented mock method");
|
|
|
|
}
|
|
|
|
|
2020-01-16 17:00:02 -08:00
|
|
|
/**
|
|
|
|
* @hide
|
|
|
|
*/
|
|
|
|
@SuppressWarnings("deprecation")
|
|
|
|
public void getTypeAsync(Uri uri, RemoteCallback remoteCallback) {
|
|
|
|
AsyncTask.SERIAL_EXECUTOR.execute(() -> {
|
|
|
|
final Bundle bundle = new Bundle();
|
|
|
|
bundle.putString(ContentResolver.REMOTE_CALLBACK_RESULT, getType(uri));
|
|
|
|
remoteCallback.sendResult(bundle);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2009-10-22 08:36:42 +09:00
|
|
|
@Override
|
|
|
|
public Uri insert(Uri uri, ContentValues values) {
|
2009-03-03 19:31:44 -08:00
|
|
|
throw new UnsupportedOperationException("unimplemented mock method");
|
|
|
|
}
|
|
|
|
|
2009-10-22 08:36:42 +09:00
|
|
|
@Override
|
|
|
|
public boolean onCreate() {
|
2009-03-03 19:31:44 -08:00
|
|
|
throw new UnsupportedOperationException("unimplemented mock method");
|
|
|
|
}
|
2009-05-15 15:10:40 -07:00
|
|
|
|
2009-10-22 08:36:42 +09:00
|
|
|
@Override
|
|
|
|
public Cursor query(Uri uri, String[] projection, String selection, String[] selectionArgs,
|
|
|
|
String sortOrder) {
|
2009-05-15 15:10:40 -07:00
|
|
|
throw new UnsupportedOperationException("unimplemented mock method");
|
|
|
|
}
|
|
|
|
|
2009-10-22 08:36:42 +09:00
|
|
|
@Override
|
|
|
|
public int update(Uri uri, ContentValues values, String selection, String[] selectionArgs) {
|
2009-03-03 19:31:44 -08:00
|
|
|
throw new UnsupportedOperationException("unimplemented mock method");
|
|
|
|
}
|
|
|
|
|
2009-10-05 14:21:12 -07:00
|
|
|
/**
|
2009-10-22 08:36:42 +09:00
|
|
|
* If you're reluctant to implement this manually, please just call super.bulkInsert().
|
2009-10-05 14:21:12 -07:00
|
|
|
*/
|
2009-10-22 08:36:42 +09:00
|
|
|
@Override
|
|
|
|
public int bulkInsert(Uri uri, ContentValues[] values) {
|
2009-05-07 17:35:38 -07:00
|
|
|
throw new UnsupportedOperationException("unimplemented mock method");
|
|
|
|
}
|
|
|
|
|
2009-10-22 08:36:42 +09:00
|
|
|
@Override
|
|
|
|
public void attachInfo(Context context, ProviderInfo info) {
|
2009-03-03 19:31:44 -08:00
|
|
|
throw new UnsupportedOperationException("unimplemented mock method");
|
|
|
|
}
|
|
|
|
|
2009-10-22 08:36:42 +09:00
|
|
|
@Override
|
|
|
|
public ContentProviderResult[] applyBatch(ArrayList<ContentProviderOperation> operations) {
|
2009-03-03 19:31:44 -08:00
|
|
|
throw new UnsupportedOperationException("unimplemented mock method");
|
|
|
|
}
|
|
|
|
|
2010-03-04 17:48:13 -08:00
|
|
|
/**
|
|
|
|
* @hide
|
|
|
|
*/
|
|
|
|
@Override
|
|
|
|
public Bundle call(String method, String request, Bundle args) {
|
|
|
|
throw new UnsupportedOperationException("unimplemented mock method call");
|
|
|
|
}
|
|
|
|
|
2016-12-02 11:35:35 -08:00
|
|
|
@Override
|
Add new ContentProvider for doing conversions to data streams.
This introduces basic infrastructure that should allow content
providers holding complex data to perform on-demand conversion
of their data to streams of various types. It is achieved through
two new content provider APIs, one to interrogate the possible
stream MIME types the provider can return, and the other to
request a stream of data in a particular MIME type.
Because implementations of this will often need to do on-demand
data conversion, there is also a utility intoduced in ContentProvider
for subclasses to easily run a function to write data into a
pipe that is read by the client.
This feature is mostly intended for cut and paste and drag and
drop, as the complex data interchange allowing the source and
destination to negotiate data types and copy (possible large)
data between them. However because it is fundamental facility
of ContentProvider, it can be used in other places, such as for
more advanced GET_CONTENT data exchanges.
An example implementation of this would be in ContactsProvider,
which can now provider a data stream when a client opens certain
pieces of it data, to return data as flat text, a vcard, or other
format.
Change-Id: I58627ea4ed359aa7cf2c66274adb18306c209cb2
2010-08-06 12:16:55 -07:00
|
|
|
public String[] getStreamTypes(Uri url, String mimeTypeFilter) {
|
|
|
|
throw new UnsupportedOperationException("unimplemented mock method call");
|
|
|
|
}
|
|
|
|
|
2016-12-02 11:35:35 -08:00
|
|
|
@Override
|
Add new ContentProvider for doing conversions to data streams.
This introduces basic infrastructure that should allow content
providers holding complex data to perform on-demand conversion
of their data to streams of various types. It is achieved through
two new content provider APIs, one to interrogate the possible
stream MIME types the provider can return, and the other to
request a stream of data in a particular MIME type.
Because implementations of this will often need to do on-demand
data conversion, there is also a utility intoduced in ContentProvider
for subclasses to easily run a function to write data into a
pipe that is read by the client.
This feature is mostly intended for cut and paste and drag and
drop, as the complex data interchange allowing the source and
destination to negotiate data types and copy (possible large)
data between them. However because it is fundamental facility
of ContentProvider, it can be used in other places, such as for
more advanced GET_CONTENT data exchanges.
An example implementation of this would be in ContactsProvider,
which can now provider a data stream when a client opens certain
pieces of it data, to return data as flat text, a vcard, or other
format.
Change-Id: I58627ea4ed359aa7cf2c66274adb18306c209cb2
2010-08-06 12:16:55 -07:00
|
|
|
public AssetFileDescriptor openTypedAssetFile(Uri url, String mimeType, Bundle opts) {
|
|
|
|
throw new UnsupportedOperationException("unimplemented mock method call");
|
|
|
|
}
|
|
|
|
|
2020-02-14 17:04:13 -08:00
|
|
|
/**
|
|
|
|
* @hide
|
|
|
|
*/
|
|
|
|
@SuppressWarnings("deprecation")
|
|
|
|
public void canonicalizeAsync(Uri uri, RemoteCallback callback) {
|
|
|
|
AsyncTask.SERIAL_EXECUTOR.execute(() -> {
|
|
|
|
final Bundle bundle = new Bundle();
|
|
|
|
bundle.putParcelable(ContentResolver.REMOTE_CALLBACK_RESULT, canonicalize(uri));
|
|
|
|
callback.sendResult(bundle);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2020-10-23 15:47:19 -07:00
|
|
|
/**
|
|
|
|
* @hide
|
|
|
|
*/
|
|
|
|
@SuppressWarnings("deprecation")
|
|
|
|
public void uncanonicalizeAsync(Uri uri, RemoteCallback callback) {
|
|
|
|
AsyncTask.SERIAL_EXECUTOR.execute(() -> {
|
|
|
|
final Bundle bundle = new Bundle();
|
|
|
|
bundle.putParcelable(ContentResolver.REMOTE_CALLBACK_RESULT, uncanonicalize(uri));
|
|
|
|
callback.sendResult(bundle);
|
|
|
|
});
|
|
|
|
}
|
|
|
|
|
2016-11-10 13:50:54 -08:00
|
|
|
/**
|
|
|
|
* @hide
|
|
|
|
*/
|
|
|
|
public boolean refresh(Uri url, Bundle args) {
|
|
|
|
throw new UnsupportedOperationException("unimplemented mock method call");
|
|
|
|
}
|
|
|
|
|
2019-05-20 14:00:17 -06:00
|
|
|
/** {@hide} */
|
|
|
|
@Override
|
|
|
|
public int checkUriPermission(@NonNull Uri uri, int uid, @Intent.AccessUriMode int modeFlags) {
|
|
|
|
throw new UnsupportedOperationException("unimplemented mock method call");
|
|
|
|
}
|
|
|
|
|
2009-10-22 08:36:42 +09:00
|
|
|
/**
|
|
|
|
* Returns IContentProvider which calls back same methods in this class.
|
|
|
|
* By overriding this class, we avoid the mechanism hidden behind ContentProvider
|
|
|
|
* (IPC, etc.)
|
|
|
|
*
|
|
|
|
* @hide
|
|
|
|
*/
|
|
|
|
@Override
|
|
|
|
public final IContentProvider getIContentProvider() {
|
|
|
|
return mIContentProvider;
|
|
|
|
}
|
2017-12-22 16:13:15 +00:00
|
|
|
|
2018-12-16 15:52:33 -08:00
|
|
|
/**
|
|
|
|
* @hide
|
|
|
|
*/
|
|
|
|
public IBinder getIContentProviderBinder() {
|
2020-05-29 10:51:18 +09:00
|
|
|
return new Binder();
|
2018-12-16 15:52:33 -08:00
|
|
|
}
|
|
|
|
|
2017-12-22 16:13:15 +00:00
|
|
|
/**
|
|
|
|
* Like {@link #attachInfo(Context, android.content.pm.ProviderInfo)}, but for use
|
|
|
|
* when directly instantiating the provider for testing.
|
|
|
|
*
|
|
|
|
* <p>Provided for use by {@code android.test.ProviderTestCase2} and
|
|
|
|
* {@code android.test.RenamingDelegatingContext}.
|
|
|
|
*
|
|
|
|
* @deprecated Use a mocking framework like <a href="https://github.com/mockito/mockito">Mockito</a>.
|
|
|
|
* New tests should be written using the
|
|
|
|
* <a href="{@docRoot}tools/testing-support-library/index.html">Android Testing Support Library</a>.
|
|
|
|
*/
|
|
|
|
@Deprecated
|
|
|
|
public static void attachInfoForTesting(
|
|
|
|
ContentProvider provider, Context context, ProviderInfo providerInfo) {
|
|
|
|
provider.attachInfoForTesting(context, providerInfo);
|
|
|
|
}
|
2009-12-09 16:00:40 -08:00
|
|
|
}
|