When a public (vfat) device is inserted, it's strongly associated
with the current foreground user, and no other users should be able
to access it, since otherwise that would be a cross-user data leak.
To use the device under a different user, switch users and then
eject/remount the device.
Test: verified user isolation of USB drive
Bug: 32523490
Change-Id: I590c791996f1fea8d78f625dc942d149f1f41614
* Extend this API to take tree URI
* Add toString(), equals() and hashCode() to Path
* Address Jeff's comments in ag/1513538
* Add unit tests for findPath
Bug: 30948740
Change-Id: Iaf852d0e40fae37623e9bb9ffa1c6fbe334c1b21
(cherry picked from commit d4ab7ade7171a4382ef4f61f2a5f078a17800e83)
Implement it in ExternalStorageProvider.
Bug: 30948740
Change-Id: I1b7717a794ae3892cd1be5ed90ca155adf9a64f4
(cherry picked from commit 51efc73f3f341393cf93f71604be791205021b69)
Implement it in ExternalStorageProvider.
Bug: 30948740
Change-Id: I03241cdfa561ef2fc0a0b829c9a59ad845e8f844
(cherry picked from commit 51efc73f3f341393cf93f71604be791205021b69)
When we create a file that already exists, we try attaching a suffix
like "(1)" to the filename to avoid the conflict. The newly added
rename method should do the same, since developers may not have
access to delete the conflicting file.
Test: boots, rename via UI, new unit tests
Bug: 31545404
Change-Id: Ie397eebb0fbf98cf079eee3bbbb6c6b7ca627d91
Otherwise we'll throw when trying to create the second (visible)
filename because we just deleted it.
Bug: 30087518
Change-Id: I940a8f81c264fc17d477fadf46fd48eae29f2f6f
The media scanner always records visible paths, so we need to use
visible paths when cleaning up deleted records.
Bug: 28581384
Change-Id: I8a2c65001216e4a96b2375579363a771de782bcc
Several changes at different levels:
1. Introduction of ejectRoot(String) for DocumentsProvider
2. Introduction of ejectRoot(ContentResolver, Uri, String) for
DocumentsContract
4. Additional permission for MOUNT_UNMOUNT for ExternalStorageProvider
5. Implementation of ejectRoot(String) for External StorageProvider
Bug: 29584653
Change-Id: I28557af63259548784cf24d5b051eb06ad5193ca
(cherry picked from commit 2ccc18357d6741dde56edc4d5a2608f15f4b9078)
There is no regular file representation for archive documents, so
the call to getFileForDocId(archivedDocId) was throwing an exception.
Bug: 27383423
Change-Id: Icbc1e8ecdddc7698cfdb79b41da6e1d3cecf11ae
A variety of related fixes:
- don't force size enable when browsing from device mounted notifications.
- don't show settings menu item as action (put in overflow).
- add sd card icon (not quite yet used, need to suss that out).
Bug:26880985,26883578,26771127
Change-Id: I36f153c42217f8092f157ded2a756c02525593ab
Add DIRECTORY_HOME to android.os.Environment...use that for dir name,
so we don't use a localized name when creating directory.
Mark all of the DIRECTORY_* fields final.
Bug: 26814341
Change-Id: I5a11bcb180674c619de2f5ce9ed598521e60cc25
It opens a an alert dialog that tells user application X is requesting
access to folder Y on volume Z; if user accepts, it returns the proper
URI, otherwise it returns RESULT_CANCELED.
The requested path must satisfy the following requirements:
1.It's directory (getName()) must be one of the pre-definied folders on
Environment.
2.It's root (getParent()) must be a valid external storage root.
In order to satisfy #2, DocumentsUI calls the ExternalStorageProvider,
through a custom call() implementation.
BUG: 23011462
Change-Id: I8e491e82ae320df88f7b8923286c4c1ad050ae80
