1506649 - Opening files from external storage should be supported too.

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, enhancement, P1)

Description

[Andrei Lazar]

See comment https://phabricator.services.mozilla.com/D9248#inline-41612

Comment 1

[Andrei Lazar]

Attachment: Bug 1506649 Opening files from external storage should be supported too. r=JanH

Trying to obtain the real path for a file located on the SD CARD will fail so we are going to
stream the data in a temporary file and make use of that path instead.

Comment 2

[Jan Henning [:JanH]]

Attachment: Bug 1506649 - Part 1: Avoid exeception-based control-flow for resolving content://-URIs. r?snorp

Instead, getOriginalFilePathFromUri() will simply *always* return null if it
cannot divine the original file path, and consequently resolveContentUri() will
then always fall back to the temp file method if getOriginalFilePathFromUri()
returns null.

Comment 3

[Jan Henning [:JanH]]

Attachment: Bug 1506649 - Part 2: Better API version linting. r?snorp

Because getOriginalFilePathFromUri() doesn't use framework methods newer than
Kitkat, instead of a generic @SuppressLint("NewAPI") it would be better to use
@TargetApi(19), so you still get warned if you start using framework methods
more recent than API19.

However because the isKitkat helper variable is only used in one place, in the
end we simply replace it with a direct Build.VERSION.SDK_INT check, so that we
don't have to use any special handling for the linter.

Comment 4

[Jan Henning [:JanH]]

Attachment: Bug 1506649 - Part 3: Guess ExternalStorageProvider file paths for non-primary volumes. r?snorp

The AOSP ExternalStorageProvider always creates document IDs of the form
"storage device ID" + ':' + "document path", where the storage device ID will
be "primary" for the primary emulated storage and the file system UUID for
everything else.

Assuming that OEMs won't customise this behaviour, the main problem that needs
to be handled is how to turn the file system UUID back into a file system path.

Comment 5

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/242e66d84734
Part 1: Avoid exeception-based control-flow for resolving content://-URIs. r=snorp
https://hg.mozilla.org/integration/autoland/rev/fd078630d666
Part 2: Better API version linting. r=snorp
https://hg.mozilla.org/integration/autoland/rev/5651b431fe2c
Part 3: Guess ExternalStorageProvider file paths for non-primary volumes. r=snorp

Comment 6

[Daniel Varga [:dvarga]]

https://hg.mozilla.org/mozilla-central/rev/242e66d84734
https://hg.mozilla.org/mozilla-central/rev/fd078630d666
https://hg.mozilla.org/mozilla-central/rev/5651b431fe2c

Comment 7

[Sorina Florean [:sflorean]]

Verified as fixed on latest Nightly build (67.0a1) and Beta build (66.0b3).

Comment 8

[Liz Henry (:lizzard) (relman/hg->git project)]

Release note added for 66: Added support to open files from external storage, such as an SD card.

Comment 9

[Jan Henning [:JanH]]

This bug was only about the built-in Android file explorer - with other file explorer apps or through manually browsing to the file location from within Firefox we have been able to open files on external storages for a long time. So I'm not sure this really warrants a release note, at least with this phrasing?