PDF app wrapping pdf.js in a WebView

[thestinger]

It would be nice to have a PDF app using a memory safe language. Ideally it would just be Java, but pdf.js might be the best PDF engine written in a memory safe language at this point along with being the closest to usable without having to create a custom UX. As a bonus, the WebView runs in an isolated_process now, so it would come with a free sandbox.

It just needs the basics of being able to receive PDFs via providers and to open them from storage.

[thestinger]

This is implemented.

[thestinger]

This is implemented.

[posativ]

What do you think about a separate application (no UI) that will add compatibility with non-contentprovider based input? E.g. register for handling PDFs and copy them into the application storage and provide a contentprovider to the actual rendering application?

[posativ]

What do you think about a separate application (no UI) that will add compatibility with non-contentprovider based input? E.g. register for handling PDFs and copy them into the application storage and provide a contentprovider to the actual rendering application?

[thestinger]

Content providers are how Android works. The built-in file manager supports them and so do any sane apps able to pass files to other apps. Android forbids passing file:/// via intents for targetSdkVersion >= 24. An app doing that is broken and not conforming to how the platform works. It's a bug that needs to be fixed for them to catch up to the current targetSdkVersion anyway and compatibility with properly written apps is another reason.

[thestinger]

Content providers are how Android works. The built-in file manager supports them and so do any sane apps able to pass files to other apps. Android forbids passing file:/// via intents for targetSdkVersion >= 24. An app doing that is broken and not conforming to how the platform works. It's a bug that needs to be fixed for them to catch up to the current targetSdkVersion anyway and compatibility with properly written apps is another reason.