search

PolarCape / polarcape-cordova-plugin-document-handler

Polar Cape Cordova Plugin Document Handler
MIT License
10 stars 19 forks source link

FileUriExposedException #27

Open maxdietrich opened 5 years ago

maxdietrich commented 5 years ago

Hello,

we use your plugin to handle links in our web app in our web app to download/open pdf documents.

This has worked fine for as long as we were on Android SDK target version 23. However, starting on the first of this month, Google imposed that all apps have to target Android SDK version 26. This is what we did, but unfortunately since then we get the following exception, when a user tries to open that link

android.os.FileUriExposedException: file:///data/user/0/$app-identifier/cache/$fileName.pdf exposed beyond app through Intent.getData()

According to this article, since Android 24 exposing file Uris via Intents is not supported. The article suggests a fix using the FileProvider API. Do you think it would be possible to change the way your library builds the Intent to use the FileProvider API?

Thanks!

vkajtazov commented 5 years ago

Hi @maxdietrich ,

Thanks for your report. I will try to find time to fix this issue, but if you meanwhile solve this, please make a pull request.

maxdietrich commented 5 years ago

Hi @vkajtazov,

I realized that the current version of the plugin already uses the FileProvider API exactly how the article I linked proposes. After upgrading to the most recent version of the plugin the error does not occur anymore. When upgrading I was a little confused though, because the JS object that is written into the window object is now called DocumentViewer instead of DocumentHandler, which is a breaking change that is not currently reflected in the documentation. I will submit a PR to update the README.

vkajtazov commented 5 years ago

Maybe it's better to revert it back to DocumentHandler, to be backward compatible.

maxdietrich commented 5 years ago

Hmm, I would disagree. Because that would mean that it is not backwarts compatible for consumers of the library who upgraded to the latest version (like me 😁). I'd argue that sticking with the current DocumentViewer would be less of a hassle instead of a breaking change and then adding another breaking change to fix it.