fix(android): handle raw document identifier

[garymathews]

• Implement handling for raw document identifier
• Prevent unhandled exception

TEST CASE

const win = Ti.UI.createWindow({ backgroundColor: 'white' });
const img = Ti.UI.createImageView();

win.addEventListener('open', _ => {
    Ti.Media.openPhotoGallery({
        success (event) {
            if (event.mediaType == Ti.Media.MEDIA_TYPE_PHOTO) {
                img.image = event.media;
            }
        },
        mediaTypes:[Ti.Media.MEDIA_TYPE_PHOTO]
    }
});

win.add(img);
win.open();

• Select photo from Downloads

JIRA Ticket

[build]

	Messages
📖	💾 Here's the generated SDK zipfile.
📖	✊ The commits in this PR match our conventions! Feel free to Rebase and Merge this PR when ready.
📖	✅ All tests are passing Nice one! All 6691 tests are passing. (There are 700 skipped tests not included in that total)

Generated by 🚫 dangerJS against f3c78fd

[sgtcoolguy]

@garymathews Does this PR supersede the community PR #11223?

[garymathews]

@sgtcoolguy Yep

[sgtcoolguy]

Can we add an Android-specific unit test for this? It's hard to trace this back to see if there's a clear cut API we can use to trigger this code path, but maybe Ti.Filesystem.getFile('content://com.android.providers.downloads.documents/document/raw%3A%2Fstorage%2Femulated%2F0%2FDownload%2Fa.pdf')

[sgtcoolguy]

code change looks OK to me, but as stated in other comment - I'd really like to see if there's any way we can test this with a URL passed in to one of our APIs...

[jquick-axway]

CR: Pass

Although I kind of want to remove all of this custom URL handling code and handle this 100% via a ContentResolver which is what we do at the bottom of this method. That's the way you're supposed to handle content:// URLs on Android. But this would mean re-testing all of the URLs we're custom handling just in case.

[ssjsamir]

FR Passed: Able to select content from downloads folder without the application crashing.

Test Steps

1. Created a Titanium application with the following test case

const win = Ti.UI.createWindow({ backgroundColor: 'white' });
const img = Ti.UI.createImageView();

win.addEventListener('open', _ => {
    Ti.Media.openPhotoGallery({
        success (event) {
            if (event.mediaType == Ti.Media.MEDIA_TYPE_PHOTO) {
                img.image = event.media;
            }
        },
        mediaTypes:[Ti.Media.MEDIA_TYPE_PHOTO]
    })
});

win.add(img);
win.open();

2. Ran the application
3. Selected downloads
4. Selected Image
5. Image displayed without the application crashing

Test Environment

MacOS Catalina 10.15.1 beta
Xcode 11.3
Node.js 10.16.3
"NPM":"4.2.15-1","CLI":"7.1.2-7"
Pixel Xl (Android 10)

[ygbr]

can we get this fix backported to 8_3_X ? Seems simple enough to apply on https://github.com/appcelerator/titanium_mobile/blob/e9ef3702af3f75327af9056ec0bb9a7bf209e130/android/titanium/src/java/org/appcelerator/titanium/io/TitaniumBlob.java#L89 and would allow 8.3.X to get android file delete working again...