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
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script that
identifies relevant "include" directives.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
Change-Id: I3480ddf2fe7ba3dfb922b459d4da01fa17a2c813
This works for target R+ apps, but need to come up with a better story
for target <R. The enforcement in DocumentsUI is target SDK based
and those apps bypass the block_tree flag.
Bug: 157320644
Test: atest DocumentsTest
Change-Id: I93aea7cd5d3b7befea1f78e1cf3f31f8250f1d33
We've been writing many new framework-specific Error Prone checkers
to help detect obscure platform bugs, and this change starts enabling
those checkers for more packages across the platform.
Bug: 155703208
Test: manual
Exempt-From-Owner-Approval: trivial blueprint changes
Change-Id: I1db3412b0be40f6f78c68331ae01756887192071
When the file is deleted, renamed or moved, revoke all uri
permissions with the file
Bug: 157474195
Test: manual test with DocumentsUI
Test: atest DocumentsTest#testAfterMoveDocumentInStorage_revokeUriPermission
Change-Id: I4ffb183630aadb2d87b0965e8cecf88af15f4534
Merged-In: I4ffb183630aadb2d87b0965e8cecf88af15f4534
(cherry picked from commit 9efd606f43)
When the file is deleted, renamed or moved, revoke all uri
permissions with the file
Bug: 157474195
Test: manual test with DocumentsUI
Test: atest DocumentsTest#testAfterMoveDocumentInStorage_revokeUriPermission
Change-Id: I4ffb183630aadb2d87b0965e8cecf88af15f4534
This change fastens the first call to DocumentsUI after reboot.
Bug: 155819706
Test: builds (fastens the first call to DocumentsUI by 600-800ms)
Change-Id: Id8396e36ed8aa1ded79d93a2f1ed140bf903184b
In Scoped Storage world, access to "Android/data" style directories are
hidden for privacy reasons. Allow ExternalStorageProvider to show these
hidden files when in manage mode.
Bug: 150366834
Test: Android/data and Android/obb is visible from Files App, but are
hidden in Picker view from StorageTestApp and Gmail (GMAIL > Compose >
Attach > Go to Pixel > Android)
Change-Id: I58b4fc23d9b479df4fc0480ae55f1f2070d0cb7c
We were listening to volume state changes in the
ExternalStorageProvider with the VOLUME_STATE_CHANGED broadcast in the
MountReceiver.
This broadcast can be severly delayed especially on user startup so we
also listen with the StorageEventListener which is more performant.
Test: Manual
Bug: 154332660
Change-Id: I93c43f3b53c0a71cd6aa7cf594fe6988f4bc3f6e
With b/150232615, we will need an explicit value set for the exported
flag when intent filters are present, as the default behavior is
changing for S+. This change adds the value reflecting the previous
default to the manifest.
Bug: 150232615
Test: TH
Change-Id: I0266b557d1c825c03508fe1a8ebdbbec39762633
We add new Documents root in MediaDocumentsProvider.
Remove unused Documents root in ExternalStorageProvider.
Bug: 148043686
Test: manual with DocumentsUI
Change-Id: I4278aa79cb1a9e22007b2946f8196d2a070be2c8
This permission will allow it access unreliable USB OTG volumes and
also service other SAF requests on the external storage.
Test: m
Bug: 144914977
Change-Id: I92f046a06852d5ba842764d8348a498b2b6ad0b7
Now that emulated volumes are per user, ESP should not register
any volume that does not match it's running user.
Bug: 144936488
Test: On device with secondary user, Files > Show internal storage
displays "internal storage"
Change-Id: If4820c684a0a8ef52cc97ae9087b1a0884f9cee7
Recent work has paved the way to get MediaStore.java building against
"core_platform", and this change is actually shifting MediaStore.java
inside the MediaProvider APEX boundary.
This involves defining a new "updatable-mediaprovider" library JAR
and ensuring that it's spliced into classpaths where needed to keep
everything building and working.
Note that the MediaProvider APK itself is still bundled, so we're
manually including the MediaStore.java when building that APK so that
we can continue referencing @hide symbols, but there's a STOPSHIP
comment to remove that once we get the APK building against
"system_current".
Bug: 144247087
Test: atest --test-mapping packages/providers/MediaProvider
Change-Id: I27ed3fde40751d9ac136a31710c62004b1b8962f
Remove the logic of using file path directly.
Parse the docId to get the relative path.
Test: atest ExternalStorageProviderTest
Change-Id: Ic218813acc73e247ee5593ed9e8e7688760e6780
Fix: 144467519
Up until now, the FUSE mount logic has made two assumptions:
1. The primary external volume is an emulated volume on /data/media
2. Only the primary user is running, as user zero
With this change, we are able to handle the following cases:
1. Mount new external storage volumes as as portable storage
(PublicVolume) managed by FUSE. The PublicVolume originally mounted on
/mnt/media_rw/<uuid> is availabe on /storage/<uuid> as a FUSE mount
2. Mount new external storage volumes as adoptable storage
(PrivateVolume) with a stacked EmulatedVolume managed by FUSE. The
EmulatedVolume orignally mounted on /mnt/expand/<uuid>/media will be
available on /storage/emulated if set as the primary storage
3. Run the MediaProvider as a secondary user handling requests on
/mnt/user/<userid>/<volid>
Test: atest AdoptableHostTest
Bug: 135341433
Bug: 140120303
Change-Id: I5fb48616b4143277ea14c6846037e2fd176e16db
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
DocumentsContract
- Add new flag FLAG_DIR_BLOCKS_TREE in Document
ExternalStorageProvider
- Add flag into DocumentInfo for blocking folder
Change-Id: Ib557fe99d330788a3bd968bffd43b6658761514f
Bug: 32370759
Test: atest DocumentsTest
We need to return visible paths for MediaProvider to work with,
instead of internal paths.
Bug: 133730441
Test: atest android.providerui.cts.MediaStoreUiTest
Change-Id: If06dc635b22032761626cf54b37b7bc15ace7b2e
Hide eject icon of removable media on the root list of Files app when
primary shared storage is in adopted media due to the following reasons.
- Primary shared storage should not be easily ejected because that
causes the situation that there's no primary shared storage
- To align with the Storage settings (Settings > Storage), eject icon
is disabled in this menu when the removable media is adopted
- Eject action from Files app can only unmount primary shared storage
Bug: 117252468
Test: manual
Change-Id: Idd76229fb10db621a817afd60295787c761345b1
1. Add the key of query arguments and match method
in DocumentsContract.
2. Implement new querySearchDocuments method in
DocumentsProvider, ExternalStoragProvider and
FileSystemProvider.
Bug: 111786939
Test: Manual Test
Change-Id: I04e9f2be971f10ac1e9584a3486c948aaddea0a4
Bug: 110380403
Test: Tested in ARC++ (with Settings and vold changes in separate CLS)
- able to see the external storage under StorageSettings. Also tested
the sm command to print stubvolumes.
Change-Id: I7517260a40399bd9800424bb394512601f6af617
Upcoming changes will prevent apps from reading "_data" columns
directly, which is required to convert between DocumentsProvider and
MediaProvider Uris. To solve this, delegate the call() through
MediaProvider, where it can perform the "_data" lookup on behalf
of the caller.
Also add new getMediaUri() call to offer symmetry.
Bug: 111960973, 117627072, 110961701
Test: atest android.provider.cts.MediaStoreUiTest
Change-Id: I53c640704d86047d7a4bf1702aca027873395abf
