I thought granting internet access to apps is not avoidable on Android.
When an app does not request internet, is it really guaranteed that it cannot talk to the outside world? Or is it having other avenues like opening a browser or some other component with a custom url or something?
Update: I just asked Gemini, and it does not look good:
An Android app without the INTERNET permission is not guaranteed to be isolated from the outside world. While it cannot make direct network connections itself, it can use several other mechanisms to transmit data externally:
Intent-Based Communication (The Browser) An app can launch an explicit or implicit Intent to hand data over to another app that does have internet access.
That means the app can open a system browser using a URL containing the data it wants to transmit.
It can also load a Chrome Custom Tab inside its own UI task, passing data through the URL string.
There is also Inter-Process Communication: If two apps from the same developer share a User ID (sharedUserId), they run in the same process and share all permissions, including internet access.
There is also the concept of Content Providers: Content Providers allow apps to share data. An offline app can write data into a shared database or a public Content Provider. A secondary, online-enabled app can then read that database and upload the contents.
This is all very true, unfortunately. Google designed Android as a an OS for internet appliances. They're not interested in local-only apps working on local files.
But I think the OP is to be complimented for what they've built and their intention in making it local-only. I've long felt that apps that *genuinely" respect privacy are one of the few areas of opportunity still left in the mobile space. I wish there were more develpers building things like this.
> That means the app can open a system browser using a URL containing the data it wants to transmit.
This can be mitigated by using an app like URLCheck [1], which you set as your default browser, and it shows and lets you edit the URL being opened before handing it off to your real browser. It also has neat features like choosing to open in incognito (if you use Firefox) and automatically removing tracking parameters.
I guess that makes sense. Since most non-privacy-focused Android distributions don't let users turn off the internet permission, keeping the permission secure likely ceased to be a priority.
The full list of bypasses is likely much larger because it doesn't fall in the scope of bug bounties.
Yeah, Android's sandbox deals with low-level file access and socket APIs and stuff. But Android also, intentionally, allows apps to expose their data and functionality to other apps via the higher-level "intent" system.
Apps get to choose what permissions are needed to access their intents, so under Android's security model, really it's Chrome's fault (or whatever browser the user has installed) for exposing an intent that allows apps that don't have the INTERNET permission to exfoltrate data.
Similarly, apps are also allowed to collude to share data with each other if they want; that's how stuff like Google Play Services works.
> Apps get to choose what permissions are needed to access their intents, so under Android's security model, really it's Chrome's fault (or whatever browser the user has installed) for exposing an intent that allows apps that don't have the INTERNET permission to exfoltrate data.
You might as well blame the phone for not being encased in concrete and thrown into a well. You might not want your text message application to have the internet permission, but you'd certainly want to be able to open links from it.
As I understand it, this "Application Sandbox" is to prevent app A seeing what app B is doing.
The problem here is a different one: The user granting an app access to their files and then having no way to prevent that app from sending that data to the developer of the app.
Great. You built an excellent tool to solve a real-world problem: being able to open files on the fly without granting internet access and without having to install 400 MB bloated suites that track everything.
pptx by a mile. A slide is absolutely positioned shapes with a whole layout inheritance thing going on so the JS renderer ends up reimplementing a whole layout engine, and it gets you to "approximately right" and stops there. Charts I gave up on.
docx was annoying in a different way. Bullets came out as junk characters for a while and I couldnt work out why. I then found that Word writes them as private use area codepoints in the Symbol font so unless you have that exact font you get some junk. I just map them back to unicode after the render.
xlsx was the easy one, SheetJS does the hard part.
On faithful though none of this is faithful the way LibreOffice is. Its more that "you can read the document and it looks roughly right" which is what I wanted out of an app of 14MB.
You don’t need internet to run JS though. And the JS seems to be pretty sandboxed in normal viewers too, so a pdf file shouldn’t make network requests on its own. As long as there is no iframe-like content I don’t see how rendering a document would ever need network.
Sorry, that's on my README. That line is under "Build from source" so it's what you need to compile it, not to run it. minSdk is 26, so Android 8 and up.
Android 14 is well past the floor, you're good to go!
> A tiny, open source, fully offline file viewer for Android that opens PDF, Word,
Perhaps correct Word to DOCX. Word is not just DOCX and DOCX is not just Word. This user needs DOC viewing and would be disappointed having installed this app.
I thought granting internet access to apps is not avoidable on Android.
When an app does not request internet, is it really guaranteed that it cannot talk to the outside world? Or is it having other avenues like opening a browser or some other component with a custom url or something?
Update: I just asked Gemini, and it does not look good:
An Android app without the INTERNET permission is not guaranteed to be isolated from the outside world. While it cannot make direct network connections itself, it can use several other mechanisms to transmit data externally:
Intent-Based Communication (The Browser) An app can launch an explicit or implicit Intent to hand data over to another app that does have internet access.
That means the app can open a system browser using a URL containing the data it wants to transmit.
It can also load a Chrome Custom Tab inside its own UI task, passing data through the URL string.
There is also Inter-Process Communication: If two apps from the same developer share a User ID (sharedUserId), they run in the same process and share all permissions, including internet access.
There is also the concept of Content Providers: Content Providers allow apps to share data. An offline app can write data into a shared database or a public Content Provider. A secondary, online-enabled app can then read that database and upload the contents.
But I think the OP is to be complimented for what they've built and their intention in making it local-only. I've long felt that apps that *genuinely" respect privacy are one of the few areas of opportunity still left in the mobile space. I wish there were more develpers building things like this.
Edit: also that LLMs are tuned for "engagement" not for answers like "it's secure enough, move along"?
This can be mitigated by using an app like URLCheck [1], which you set as your default browser, and it shows and lets you edit the URL being opened before handing it off to your real browser. It also has neat features like choosing to open in incognito (if you use Firefox) and automatically removing tracking parameters.
[1] https://f-droid.org/packages/com.trianguloy.urlchecker
The full list of bypasses is likely much larger because it doesn't fall in the scope of bug bounties.
Good grief. What a huge vulnerability. Is there some benefit that justifies this?
You need something like that for plugin / extension like system.
Third, it is being deprecated. and people are screaming "bad google" "android is no longer free!"
I'm assuming that all works even with application sandboxing (1) or am I mis-reading how that is applied to applications.
Man I need to move my movement to GrapheneOS up to be sooner.
(1) https://source.android.com/docs/security/app-sandbox
Apps get to choose what permissions are needed to access their intents, so under Android's security model, really it's Chrome's fault (or whatever browser the user has installed) for exposing an intent that allows apps that don't have the INTERNET permission to exfoltrate data.
Similarly, apps are also allowed to collude to share data with each other if they want; that's how stuff like Google Play Services works.
You might as well blame the phone for not being encased in concrete and thrown into a well. You might not want your text message application to have the internet permission, but you'd certainly want to be able to open links from it.
The problem here is a different one: The user granting an app access to their files and then having no way to prevent that app from sending that data to the developer of the app.
1. Markdown loads as preview
2. Plain text files wrap instead of scrolling to the right
Good job and thank you for sharing
How is accessibility? Do PDFs work with screenreaders for example?
docx was annoying in a different way. Bullets came out as junk characters for a while and I couldnt work out why. I then found that Word writes them as private use area codepoints in the Symbol font so unless you have that exact font you get some junk. I just map them back to unicode after the render.
xlsx was the easy one, SheetJS does the hard part.
On faithful though none of this is faithful the way LibreOffice is. Its more that "you can read the document and it looks roughly right" which is what I wanted out of an app of 14MB.
> Requirements: JDK 17+ and the Android SDK (platform 35).
Bummer. I am stuck with Android 14 for the moment.
Android 14 is well past the floor, you're good to go!
> A tiny, open source, fully offline file viewer for Android that opens PDF, Word,
Perhaps correct Word to DOCX. Word is not just DOCX and DOCX is not just Word. This user needs DOC viewing and would be disappointed having installed this app.
I wish you every success with this.