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
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
We thought we could push everyone through sdcardfs, but secondary
devices mounted in a stable location don't give full write access to
apps holding WRITE_EXTERNAL_STORAGE, so system internals still need
to reach behind sdcardfs.
To keep sdcardfs in the loop about changes that we make behind its
back, we issue access(2) calls which should be enough for it to
invalidate any cached details.
Bug: 74132243
Test: manual
Change-Id: I727cd179a5a825b16ec4df6e2f41a079758d41c5
This change sets LOCAL_SDK_VERSION for all packages where
this is possible without breaking the build, and
LOCAL_PRIVATE_PLATFORM_APIS := true otherwise.
Setting one of these two will be made required soon, and this
is a change in preparation for that. Not setting LOCAL_SDK_VERSION
makes the app implicitly depend on the bootclasspath, which is
often not required. This change effectively makes depending on
private apis opt-in rather than opt-out.
Test: make relevant packages
Bug: 73535841
Change-Id: I4233b9091d9066c4fa69f3d24aaf367ea500f760
If we have a policy that says DISALLOW_USB_FILE_TRANSFER, then block
file transfers for that user through common ContentProviders.
Test: builds, boots
Bug: 64672411
Change-Id: I502b10c2c229727bc6b421f9db6d2d9e2e03845c
For volumes where the OS manages cached data, use the "free space" as
reported by StorageStatsManager, which is the same value shown in
the Settings app and other UI elements.
Also, when the storage space changes significantly, invalidate anyone
who was holding a cached "free space" value.
Test: builds, boots
Bug: 38146029
Change-Id: I4b3a484a8bf32cd137a83f1ea441beca6dc6719a
It's confusing, but f_bsize is not the value you're looking for; the
real block size is f_frsize. Fix all those bugs.
Also, the vast majority of clients are interested in the usable
disk space, not including reserved space.
Test: builds, boots
Bug: 36840579
Change-Id: Ib1470389afd49c14cab62282ec1e978ebb2c4791
Update DocumentsProvider to override
ContentProvider#query(Uri, String[], Bundle, CancellationSignal);
Added an otherwise unneeded import to pass doc check
on DocumentsProvider.
Bug: 30927484
Change-Id: I295c21f53901d567455286f22439f21d22a8a25a
Test: Build and run. Test from DocsUi.
getDocumentUri(String, List<UriPermission>) needs it because MediaStore
can only provide path under visible paths for external SD cards.
Test: Manual test w/ SD card. Relative CTS tests pass. Happy to add
automated tests for SD card cases if somebody shows me how.
Bug: 33819522
Change-Id: I15cdd60a2d2c94275dd661f20b5b0deb0d80d258
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
