| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
This CL is basically identical to http://ag/10353234, which
did the same with the sister method, "canonicalize".
Fixes: b/147705670
Test: atest FrameworksCoreTests:android.content.ContentResolverTest
Change-Id: Ide93850f225cdd61779a62fc2c4666efe438b536
|
| |
|
|
|
|
| |
Fixes: b/147699082
Test: atest FrameworksCoreTests:android.content.ContentResolverTest
Change-Id: I2e851839a454ad5eabc981c76774d03b57a1aa09
|
| |
|
|
|
|
|
| |
Fixes: b/147646960
Test: atest FrameworksCoreTests:android.content.ContentResolverTest
Change-Id: I04c15ac008fe14b215f954af150226dc94f22232
|
| |
|
|
|
|
|
|
| |
Existing annotations in libcore/ and frameworks/ will deleted after the migration. This also means that any java library that compiles @UnsupportedAppUsage requires a direct dependency on "unsupportedappusage" java_library.
Bug: 145132366
Test: m && diff unsupportedappusage_index.csv
Change-Id: I6ab53570aca580fbee1fcc927871caa09780f58f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A few releases ago we added ContentResolver.QUERY_ARG_* constants
to query() as a new best-practice that will help wean us off raw
SQL arguments. (For example, a provider could add their own
custom arguments like QUERY_ARG_INCLUDE_PENDING to cause the query
to reveal pending items that would otherwise be hidden.) This
change expands update() and delete() to accept those arguments.
This change also expand insert() to accept extras too, as part of
preparing to support an upcoming MediaProvider feature that will let
apps place new media "adjacent" to an existing media item. (Sending
that adjacent item through extras is cleaner than trying to send it
through escaped query parameters.)
Bug: 131643582
Test: atest CtsContentTestCases
Change-Id: I436296155b9b5f371b4cbe661feaf42070285fcc
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This takes the Context#getFeatureId from the calling context and pipes
it all way through to the noteOp calls done by the content provider.
Bug: 136595429
Test: atest CtsAppOpsTestCases (new test added to capture this case)
TelecomUnitTests:CallLogManagerTest
ContentProviderClientTest
TelecomUnitTests:MissedCallNotifierImplTest
TelecomUnitTests:BasicCallTests
MediaInserterTest
PreferencesHelperTest
RankingHelperTest
PinnedSliceStateTest
FrameworksCoreTests:ContentResolverTest
Change-Id: I53b1035626229c920b353509a5bece157b52fb51
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The new MediaProvider design has an internal dynamic security model
based on the value stored in OWNER_PACKAGE_NAME, so the OS always
needs to consult the provider when resolving Uri permission grants.
Blocking calls from the system process like this are typically
discouraged, but this is the best we can do with the limited time
left, and there is existing precident with getType().
For now, use "forceUriPermissions" as a proxy for determining when
we need to consult the provider directly.
Bug: 115619667
Test: atest --test-mapping packages/providers/MediaProvider
Test: atest android.appsecurity.cts.ExternalStorageHostTest
Change-Id: I1d54feeec93fbb4cf5ff55240ef4eae3a35ed068
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For packages:
android.app.admin
android.app.backup
android.app.job
android.app.usage
android.content
android.content.om
android.content.pm
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: Id84ee490f3435a196fca10a89bda9f7217b750c6
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Existing APIs that accept a ContentResolver are too restrictive when
the caller has their own ContentProviderClient already bound and
configured, so we're in the market for a solution to open those
existing APIs to accept a wider range of inputs.
The solution we've come up with is to introduce a super-interface
which contains the common ContentProvider APIs, and then make
ContentProvider, ContentResolver, and ContentProviderClient all
implement that interface for consistency.
After this change lands, we can then safely relax existing APIs to
accept this new ContentInterface, offering a clean path to solving
the problem outlined above.
Bug: 117635768
Test: atest android.content.cts
Test: atest android.provider.cts
Change-Id: Ic5ae08107f7dd3dd23dcaec2df40c16543e0d86e
Exempted-From-Owner-Approval: keep tests working
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For packages:
android.content.res
android.content.pm.split
android.content.pm.permission
android.content.pm.dex
android.content.pm
android.content.om
android.content
This is an automatically generated CL. See go/UnsupportedAppUsage
for more details.
Exempted-From-Owner-Approval: Mechanical changes to the codebase
which have been approved by Android API council and announced on
android-eng@
Bug: 110868826
Test: m
Change-Id: Ia79256a3d04e16dd78331a61af0dcddc5fc1599b
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Auto-paging of cursors is being removed in favor of a support lib component.
Rationale:
1) Auto-paging as implemented has potential to negatively impact system health.
2) Similar functionality w/o system health concerns can be provided
specific to RecyclerView.
Test: Removed. CTS coverage updated.
Bug: 30927484
Change-Id: I43e62181d8ceeeba6265d44536967a2102751320
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Allow all client targeting Android O to assume paging
support for any provider.
Adds a new PageViewCursor that adapts an unpaged cursor
to a paged request.
Updates ContentProviderNative to perform wrapping on
unpaged results.
Bug: 30927484
Change-Id: I4e225dc16761793c85ef8a195bf049113c79cd20
Test: Added for new class. Run info @ frameworks/base/core/tests/coretests/README
|
| |
|
|
|
|
| |
Test: cts-tradefed run cts-dev -m CtsContentTestCases
Bug: 30927484
Change-Id: Idb9dbc2b80896e9f8474a0db71353b7a3810d597
|
| |
|
|
|
|
|
| |
Original CL is from ag/1568530.
Bug: 31647485
Change-Id: Ib45fc995a361b8c75cd3600f638910b18a263d51
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To protect system stability, any Binder calls leaving the
system_server must carefully be performed using FLAG_ONEWAY (or
the 'oneway' verb in AIDL) which prevents the call from blocking
indefinitely on the remote process.
In this CL, the system_server uses the new Binder.setWarnOnBlocking()
method to enable detection by default for all remote Binder
interfaces. It can also use Binder.allowBlocking() to allow
blocking calls on certain remote interfaces that have been
determined to be safe.
This CL adds the 'oneway' verb to several interfaces and methods
where it should have been added, and marks a handful of system
ContentProviders as being safe to call into. Also, we assume that
any services obtained from ServiceManager are part of the core
OS, and are okay to make blocking calls to.
Test: builds, boots, runs with minimal logs triggered
Bug: 32715088
Change-Id: Ide476e120cb40436a94b7faf7615c943d691f4c0
|
| |
|
|
|
|
|
|
| |
android.content.ContentProviderProxy.openFile.
BUG=20693984
Change-Id: Id089d218057d5439da1bd5bf0ce3991059c1ecad
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
All but a few lines of this is for issue #16013164, which allowed
apps to do some operations as the media uid by having it call
back to them to open a file. The problem here is with the tempory
identity stuff in the activity manager, allowing us to make the open
call as the original caller... ideally we should figure out a way
to just get rid of all of that, but the solution here is actually
easier (even though it doesn't look it) -- we now hand a token over
to the openFile() call that it can use when doing permission checks
to say "yes I would like the check to be against whoever is responsible
for the open". This allows us to do the uid remapping for only this
one specific set of permission checks, and nothing else.
Also fix issue #17487348: Isolated services can access system services
they shouldn't be able to. Don't send any system service IBinder objects
down for the first initialization of an isolated process.
Change-Id: I3c70e16e0899d7eef0bae458e83958b41ed2b75e
|
| |
|
|
|
|
|
| |
If a query call was cancelled, the cursor adaptor might leak. The
adaptor is now closed if any exception is thrown during query.
Change-Id: Ic4c2edeaf2fcef56b4ef59484a36d3233aa12dbc
|
| |
|
|
|
|
|
|
|
| |
...in settings > sound
Add a new ContentProvider API to canonicalize URIs, so they can
be transported across backup/restore.
Change-Id: Ie5af3662f6822a32310e49c7f1e1ff084986c56e
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since ContentProvider file operations can end up doing substantial
network I/O before returning the file, allow clients to cancel their
file requests with CancellationSignal.
Ideally this would only be needed for openFile(), but ContentResolver
heavily relies on openAssetFile() and openTypedAssetFile() for common
cases.
Also improve documentation to mention reliable ParcelFileDescriptors
and encourage developers to move away from "rw" combination modes,
since they restrict provider flexibility. Mention more about places
where pipes or socket pairs could be returned.
Improve DocumentsContract documentation.
Bug: 10329944
Change-Id: I49b2825ea433eb051624c4da3b77612fe3ffc99c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Implemented reading and writing state to retain information
across boots, API to retrieve state from it, improved location
manager interaction to monitor both coarse and fine access
and only note operations when location data is being delivered
back to app (not when it is just registering to get the data at
some time in the future).
Also implement tracking of read/write ops on contacts and the
call log. This involved tweaking the content provider protocol
to pass over the name of the calling package, and some
infrastructure in the ContentProvider transport to note incoming
calls with the app ops service. The contacts provider and call
log provider turn this on for themselves.
This also implements some of the mechanics of being able to ignore
incoming provider calls... all that is left are some new APIs for
the real content provider implementation to be involved with
providing the correct behavior for query() (return an empty
cursor with the right columns) and insert() (need to figure out
what URI to return).
Change-Id: I36ebbcd63dee58264a480f3d3786891ca7cbdb4c
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that the Cursor object is closed if a query on a
content provider fails due to an error or is canceled during
execution. There are several places in the code where
similar problems can occur.
To further reduce the likelihood of leaks, close the cursor
window immediately when a query fails.
Bug: 7278577
Change-Id: I8c686c259de80a162b9086628a817d57f09fdd13
|
| |
|
|
|
| |
Bug: 6427830
Change-Id: I39451bb1e1d4a8d976ed1c671234f0c8c61658dd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If the remote end of a bulk cursor died, then it was possible
for getColumnNames() to return null, violating the invariant
that it never returns null. As a result, the application could
crash in strange ways due to an NPE.
Since we are often interested in the column names anyhow, prefetch
them when setting up the bulk cursor adaptor. This way, a
remote cursor will never return null even if the remote end died.
It is possible for an application to continue to use a remote cursor
even after the provider has died unless it needs to requery it
for some reason. Of course at that point, bad things will
happen... but usually the app is better prepared for it than
if it just randomly encounters a null array of column names.
This change also optimizes the bulk cursor adaptor to return the
initial cursor window back to the client, potentially saving
an extra RPC. Because the communication protocol between
the CursorToBulkCursorAdaptor and BulkCursorToCursorAdaptor was
getting a little hard to follow, introduced a new type called
BulkCursorDescriptor to hold all of the necessary parameters.
Deleted several unnecessary IBulkCursor methods that are never
actually called remotely.
Bug: 6168809
Change-Id: I9aaf6f067c6434a575e2fdbf678243d5ad10755f
|
| |
|
|
|
| |
Bug: 5943637
Change-Id: I12a339f285f4db58e79acb5fd8ec2fc1acda5265
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Added new API to enable cancelation of SQLite and content provider
queries by means of a CancelationSignal object. The application
creates a CancelationSignal object and passes it as an argument
to the query. The cancelation signal can then be used to cancel
the query while it is executing.
If the cancelation signal is raised before the query is executed,
then it is immediately terminated.
Change-Id: If2c76e9a7e56ea5e98768b6d4f225f0a1ca61c61
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug: 5332296
The memory dealer introduces additional delays for reclaiming
the memory owned by CursorWindows because the Binder object must
be finalized. Using ashmem instead gives CursorWindow more
direct control over the lifetime of the shared memory region.
The provider now allocates the CursorWindows and returns them
to clients with a read-only protection bit set on the ashmem
region.
Improved the encapsulation of CursorWindow. Callers shouldn't
need to care about details like how string fields are allocated.
Removed the compile-time configuration of string and numeric
storage modes to remove some dead weight.
Change-Id: I07c2bc2a9c573d7e435dcaecd269d25ea9807acd
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Bug: 5332296
Ensure that there is always an owner for each CursorWindow
and that references to each window are acquired/released
appropriately at all times.
Added synchronization to CursorToBulkCursorAdaptor to
prevent the underlying Cursor and CursorWindow from being
remotely accessed in ways that might violate invariants,
resulting in leaks or other problems.
Ensured that CursorToBulkCursorAdaptor promptly releases
its references to the Cursor and CursorWindow when closed
so they don't stick around longer than they should, even
if the remote end hangs onto the IBulkCursor for some reason.
CursorWindow respects Parcelable.FLAG_WRITE_RETURN_VALUE
as an indication that one reference to the CursorWindow is
being released. Correspondingly, CursorToBulkCursorAdaptor
acquires a reference to the CursorWindow before returning
it to the caller. This change also prevents races from
resulting in the transfer of an invalid CursorWindow over
the wire.
Ensured that BulkCursorToCursorAdaptor promptly releases
its reference to the IBulkCursor when closed and throws
on attempts to access the cursor while closed.
Modified ContentProviderNative to handle both parts of
the wrapping and unwrapping of Cursors into IBulkCursors.
This makes it a lot easier to ensure that the right
things happen on both ends. Also, it turns out that
the only caller of IContentProvider.bulkQuery was
ContentProviderNative itself so there was no need
to support bulkQuery on ContentProviderProxy and it was
just getting in the way.
Implement CloseGuard on CursorWindow.
Change-Id: Ib3c8305d3cc62322f38a06698d404a2989bb6ef9
|
| |
|
|
|
|
|
|
|
| |
Bug: 5332296
We can't replace these with AIDL generated proxies just yet, but
at least we can make them a little more conformant.
Change-Id: I1814f76d0f9c5e44a7fd85a12b2e3c2b7e3c9daa
|
| |
|
|
|
|
|
|
| |
- do the reply.writeNoException() only if there are NO exceptions
- before, the code could actually generate an exception when asking for the count or the index,
and then the exception could not be unmaarshalled because we previously calling reply.writeNoException()
Change-Id: I241120878c3fc10fea5fbaeb74f9124b1413a3d4
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When query() uses bulkQuery() and we know we're going to need some
metadata right afterwards (number of rows and column index of _id, if
present), just asked for it in the initial binder transaction instead
of immediately fetching it again.
Also, this defers loading column names until the client asks for them.
This gets down the simpler (and very common) use cases of
ContentProvider.query() down to 3 binder calls:
QUERY_TRANSACTION to android.content.ContentProvider$Transport
GET_CURSOR_WINDOW_TRANSACTION to android.database.CursorToBulkCursorAdaptor
CLOSE_TRANSACTION to android.database.CursorToBulkCursorAdaptor
More can still be done, but this is a good bite-sized first piece.
Change-Id: I7ad45949f53e0097ff18c2478d659f0f36929693
|
| |
|
|
|
|
|
|
|
| |
This manifested itself as memory allocation and Binder failures during
my load testing / benchmarking.
BUG=2498615
Change-Id: I260fd916f97777fc98bee98d10474f12deb21dee
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This permits implementing interfaces which are faster than using
remote Cursors. It then uses it for Settings & SettingProvider, which
together account for ~50% of total ContentProvider event loop stalls
across Froyo dogfooders.
For fetching Settings this looks like it should reduce average
Settings lookup from 10 ms to 0.4 ms on Sholes, once the
SettingsProvider serves most gets from in-memory cache. Currently it
brings the Sholes average down from 10ms to 2.5 ms while still using
SQLite queries on each get.
|
| |
|
|
|
|
|
|
|
| |
removed the parcelling ability from Entity and EntityIterator and made them public - added an EntityIterator abstract implementation that allow easy wrapping of a Cursor - changed the VCard c
Merge commit '328c0e7986aa6bb7752ec6de3da9c999920bb55f' into eclair-mr2-plus-aosp
* commit '328c0e7986aa6bb7752ec6de3da9c999920bb55f':
- removed the concept of Entity from the ContentProvider APIs
|
| |
|
|
|
|
|
| |
- remove updateEntity and insertEntity, since they are not
used
- add the RawContacts.Entity class, which is used in lieu of the
android.content.Entity
|
| |
|
|
| |
- clean up the debug printing of SyncResult
|
| |
|
|
|
|
| |
- change the applyBatch to take an ArrayList rather than an []
- change Entity to be a final flass that contains ContentValues
- remove the ability to update/insert Entities by a ContentProviderOperation
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
