[CB-10093][CB-9960][android] fix error resolving content uri to file url

[sencenan]

fixing: https://issues.apache.org/jira/browse/CB-10093

Different app returns different uri. This is causing getRealPath() to return empty path.

Fixed:

• Gallery: content://media/external/images/media/117209
• Google Photo: embeds a external image link inside another uri
• Dropbox: old school file url

Not fixed:

• Google Drive: document uri, but has no document id, or the id cannot be used to query content resolver

Notes:

I have tested with: Gallery, Dropbox, Google Photo, and various file manager apps. However, this fix as is still does not address the problem with Google Drive.

It seems to me that trying to get real file path from content uri is a fundamentally flawed solution. It breaks the sandbox between apps and this is going to get worse when more apps start to return the URL in "non-standard" formats.

Use getContentResolver().openInputStream() and read the file directly could be a way forward, given that we are copying/rewriting the image file already.

For reference, I am using this following hack on my own branch to address the problem with Google Drive:

private String ouputModifiedBitmap(Bitmap bitmap, Uri uri) throws IOException {
        // Some content: URIs do not map to file paths (e.g. picasa).
        String realPath = FileHelper.getRealPath(uri, this.cordova);

        //START OF HACK
        if (realPath.length() == 0) {
            String copiedFilePath = getTempDirectoryPath() + "/"
                    + System.currentTimeMillis() + ".copied."
                    + (this.encodingType == JPEG ? "jpg" : "png");

            InputStream fin = this.cordova.getActivity().getContentResolver().openInputStream(uri);
            OutputStream fout = new FileOutputStream(copiedFilePath);

            byte[] buf = new byte[1024 * 4];
            int len;

            while ((len = fin.read(buf)) > 0) {
                fout.write(buf, 0, len);
            }

            fin.close();
            fout.close();

            realPath = copiedFilePath;
        }
        //END OF HACK

        // rest of ouputModifiedBitmap method
}

[purplecabbage]

Copy the image to an app accessible temp location and return that url.

[riknoll]

@purplecabbage @sencenan I agree that getting the file path out of a content URI is becoming too convoluted to be sustainable. Getting the InputStream from the ContentResolver comes with it's own awkwardness as well, however, due to Android's ExifInterface class. We use that class to extract the EXIF data and preserve it as we modify the image (for quality, orientation, etc.). Unfortunately, it does not take in an InputSteam and so we would have to find/code a new EXIF reader or do something weird with writing the image twice (copy image to temp location -> read EXIF from temp image -> overwrite temp image with modified image -> return temp image URI). Thoughts?

[sencenan]

@riknoll that's my finding too with regard to ExifInterface class. I do think copying the image could be a viable solution like @purplecabbage said. Not entirely sure about the performance implications though.

[bgaillard]

Hi, I think this Pull Request is very important, for now we cannot propose to the user of our applications to pick a picture.

Is the Cordova team planning to merge this PR soon ?

Thanks

[infil00p]

This isn't going to be merged since we changed how we resolve file paths. That's also why this doesn't merge cleanly.