From Newsgroup: comp.mobile.android

New-to-me tablet that someone gave back that I had given them as a gift.

I was copying an already-unzippled set of 25,000 html and JPEG files for a
book from Windows to an Android tablet but it was taking forever (hours) so
I stopped it and copied only the 500MB zip file in just a minute or two,
but now that it's on Android how do I best unzip it so it works as HTML.

Looking it up, apparently most people unzip using Files by Google or My
Files on Samsung, but for a more universal solution, I tested ZArchiver freeware which has unzip capabilities so everyone here can benefit.
<https://zdevs.ru/en/za/apk.html>
<https://play.google.com/store/apps/details?id=ru.zdevs.zarchiver>

Having used computers since they were available to the4 public, I know
enough to put everything on Android in my own unpolluted folders only.

Hence, I use 0000 on internal storage and 0001 on external storage.

The reason for the zeroes is that it becomes the FIRST thing we see in the crappy Android file browsers, so I know instantly what storage I'm in 'cuz Android pollutes both the internal storage and external storage similarly
so we won't even know which one we are in sometimes but I can see the 0000
or 0001 and I know which storage location I'm in, instantly.

So I put the zip file, which we'll call "name.zip" in
/storage/emulated/0/0000/doc/book.zip (names have been simplified)

Here's how I unzipped the 500MB book.zip file containing html & jpeg:
1. Open ZArchiver
2. Navigate to /storage/emulated/0/0000/doc/ & tap book.zip
3. Choose Extract... (out of the too-many extraction choices)
4. When it asks to "Pick a destination folder" just hit the blue arrow
5. Wait for extraction (mine asked if I wanted to keep the screen on)
25K files took a few minutes on my Android 16 Samsung tablet
6. In my case, it created a folder of the same name as the zip file was
7. I opened the newly created folder and tapped index.html
8. In my case, it asked what to open it with so I chose a "Chrome" browser
It opened the index.html but everything was broken after that.
Yet, it worked fine on Windows doing the same steps.
So Chrome can access the files, apparently.

I put the zip in /storage/emulated/0/0000/book/name.zip and I had extracted
to /storage/emulated/0/0000/book/name/ but apparently some browsers aren't
able to open files correctly from outside of standard known directories.

I'm not sure why Chrome failed, but as a first test to solve that failure I installed the FOSS Browser (yes, it's called that)
FOSS Browser
A fully free (as in freedom) open source browser for Android.
<https://f-droid.org/en/packages/de.baumann.browser/>
<https://f-droid.org/repo/de.baumann.browser_158.apk>
Name: de.baumann.browser_158.apk
Size: 6361844 bytes (6212 KiB)
SHA256: 5D1FDCC15C5919645F55F10F69DDB1755E6EF2187F2F829E7C919ADF24E82A9A

Opening the FOSS browser on Android is an experience in controlled
confusion because it opens to a wiki which takes over the whole browser.
Worse, that wiki causes the FOSS browser to crash on my Android tablet.
The crashes are java error from their own wiki web page, which is dumb.

Working around that, I try the "file open" dialog by tapping on
/storage/emulated/0/0000/book/name/index.html
but the FOSS Browser apparently does NOT register itself with Android as an
app that can open HTML files. So I type the full path, which then says: file:///storage/emulated/0/0000/book/name/index.html could not be loaded because: net::ERR_ACCESS_DENIED

Apparently FOSS browser just can't access your own priate folders. Sigh.
When Android 10+ introduced "scoped storage, things like this broke
because apps cannot read arbitrary folders unless they use the Storage
Access Framework so my top-level folders are not accessible to browsers
unless they implement SAF

Apparently, FOSS Browser does not implement SAF.
a. It does not request modern permissions.
b. It does not declare HTML MIME types.
c. It does not register itself as a file opener.
d. It does not handle file:// outside public folders.

So Android blocks it with: ERR_ACCESS_DENIED
So I'll switch browsers to one that does implement SAF, I guess.
--
Usenet allows good friends around the world to discuss their experiences.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

So Android blocks it with: ERR_ACCESS_DENIED
So I'll switch browsers to one that does implement SAF, I guess.

I deleted the horrid FOSS Browser and next tried the F-Droid Privacy
Browser:

<https://fdroid.gitlab.io/jekyll-fdroid/packages/com.stoutner.privacybrowser.standard/>
<https://f-droid.org/repo/com.stoutner.privacybrowser.standard_81.apk>
Name: com.stoutner.privacybrowser.standard_81.apk
Size: 17083571 bytes (16 MiB)
SHA256: 209E0670CB44A959DD628737EAA5B8DF05BFB605E4706DE49EA2B72684CF72E3

Drat. When I went to ZArchiver and tapped on the index.html file, it opened
up
but when I tapped on one of the sub links, it said "webpage not available".

The webpage at content://ru.zdevs.sarchiver.external/storage/emulated/0/0000/book/gages/2.html
could not be loaded because: net::ERR_FILE_NOT_FOUND

So I opened Privacy Browser and tapped the browser "Browse" button which allowed me to find the file which its own URL became, cryptically,

content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html
That opened the top level of the index.html page.

When I clicked on a lower-level link, it asked me to "open with" but the options provided did not include a browser.
Muntashirakon App Manager interpreter, Google (search), Messages, Messages
The Muntashirakon App Manager interceptor shows
Action = android.intent.action.VIEW
Data =
content://com.android.externalstorage.documents/document/pages/2.html

Yikes. What's happening? This isn't a real file-system path at all.
It's an SAF document URI.
--
Every version of Android makes things harder, much like what iOS does.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

Data =
content://com.android.externalstorage.documents/document/pages/2.html
Yikes. What's happening? This isn't a real file-system path at all.
It's an SAF document URI.

The index.html is written using normal standard relative links such as
pages/2.html
images/foo.png
css/style.css

These only work if the browser knows the real directory.
But the fashuganeh Android SAF apparently hides the directory.

Therefore, SAF URIs cannot be used for relative links inside HTML files.
So when the HTML says: <a href="pages/2.html">
Android tries to resolve it relative to the SAF URI, not the filesystem.

Worse, when I tap an HTML file in ZArchiver, it passes the file using
content://ru.zdevs.zarchiver.external/...
Which is ZArchiver's own SAF wrapper, not a real path.

When I paste the full URI into Privacy Browser, I get the error
Webpage not available.
The webpage at file:///storage/emulated/0/0000/book/name/index.html
could not be loaded because: net::ERR_ACCESS_DENIED

The normal HTML manual expects a real filesystem:
/storage/emulated/0/0000/book/name/index.html
/storage/emulated/0/0000/book/name/pages/2.html
But Android 16 rewrites everything into SAF URIs:
content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html

This means the relative link
pages/2.html
Becomes
content://com.android.externalstorage.documents/document/pages/2.html
which is not a real path. It's a virtual document reference.

So why did file:///storage/emulated/0/0000/book/name/index.html fail?
Android 10+ treats any custom top-level folder as restricted.

Apparently, Android only allows browsers to read:
/storage/emulated/0/Download/
/storage/emulated/0/Documents/
/storage/emulated/0/DCIM/
/storage/emulated/0/Pictures/

Apparently, Occam's Razor says the simplest explanation that fits the facts is that Android 16 blocks browsers from reading custom top-level folders.
--
Every Usenet post should strive to add value that wasn't there before.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

Apparently, Android only allows browsers to read:
/storage/emulated/0/Download/
/storage/emulated/0/Documents/
/storage/emulated/0/DCIM/
/storage/emulated/0/Pictures/

This is frustrating as Android seems to be getting more & more like iOS
as it appears that Android's WebView (used by all browsers) cannot open:
file:///storage/emulated/0/0000/...

So I need to find an app that still use direct POSIX filesystem access (and ignores SAF entirely), or, I can install a local HTTP server in Termux.

Apparently, these file managers have their own internal HTML renderer
that bypasses WebView, so I might resort to testing these one by one.
a. MiXplorer (best option)
b. X-plore
c. Older versions of Cx File Explorer

But I think the most reliable will be to use Termux, which can access /0000 directly because it uses POSIX APIs (not SAF), and then start a server.

1. Install Termux from Github/FDroid (never use the Termux on Google Play)
<https://f-droid.org/en/packages/com.termux/>
<https://github.com/termux/termux-app>
<https://github.com/termux/termux-app/releases/tag/v0.118.3>
<https://github.com/termux/termux-app/releases/download/v0.118.3/termux-app_v0.118.3+github-debug_arm64-v8a.apk>
Name: termux-app_v0.118.3+github-debug_arm64-v8a.apk
Size: 35106607 bytes (33 MiB)
SHA256: 72FDB596045116BF5BA1B5BDF5B26FDDB9ACC0BD074AD9F2DA9EB0AE85E83A4E

2. In Termux, navigate to the folder containing the index.html manual
$ cd /storage/emulated/0/0000/book/name
Drat. I got "permission denied".
Termux didn't ask for permissions other than "Notifications".
So we need to manually set the permissions to see files.
Settings > Apps > Termux > permissions > Files
Test with:
$ ls /storage/emulated/0/0000/book/name

3. In Termux, install python.
$ pkg install python

4. In Termux, start the server
$ python3 -m http.server 8000
Serving HTTP on :: pot 8000 (http://[::]:8000) ...

5. Open any browser and type the following into the url address field
http://localhost:8000

6. Using the Privacy Browser, that brought up the top-level web page.
Then, I tapped on the first link... ... ... Voila!
The manual page2 showed up perfectly this time.

Whew!
Success at last!

I finally forced Android 16 to behave like a real operating system again.
I carved out a sane workflow inside an OS that keeps trying to turn into
iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.
--
Intelligent people rarely fail at doing what they want to do on Android.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again.
I carved out a sane workflow inside an OS that keeps trying to turn into iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!)

Windows and Linux can easily open HTML books stored in custom top-level hierarchies, even if the books contain tens of thousands of pages & jpegs.

Unfortunately, Android 10 through 16 cannot open HTML book stored in custom top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

All Android web browsers use WebView, which is restricted by Scoped Storage and the Storage Access Framework (SAF). When you try to open index.html, Android does not give the browser the real filesystem path.

Instead it rewrites the path into a SAF URI like:
content://com.android.externalstorage.documents/document/primary%3A0000%2Fbooks%2Fbook1%2Findex.html

SAF URIs are not real filesystem paths.
Because of this, all relative links inside the book1 break.

For example:
pages/2.html
images/foo.png
css/style.css

These links get rewritten into invalid SAF document URIs such as:
content://com.android.externalstorage.documents/document/pages/2.html

Browsers cannot resolve these, so they fail with errors like
ERR_ACCESS_DENIED and ERR_FILE_NOT_FOUND.

Android WebView only allows file:// access in a few public folders
(Download, Documents, DCIM, Pictures) but Linux users often use custom
folders like /usr/local so that they can back up everything they care about easily, and so that they're not polluted by the Android system.

Custom folders like /0000 are blocked.

Unzipping the book1 works fine, but opening index.html directly from
the top-level /0000 fails in every browser tested.

Solution:
Use Termux to bypass SAF entirely. Termux uses real POSIX filesystem
access. After granting Termux full file permissions in Android Settings,
you can run a local HTTP server that serves the book1 using real paths.

Steps:
1. Install Termux from GitHub or F-Droid.
2. Grant Termux "All files access" in Android Settings.
3. In Termux, install Python:
pkg install python
4. Navigate to the book1 directory:
cd /storage/emulated/0/0000/books/book1
5. Start a local HTTP server:
python3 -m http.server 8000
6. Open any browser and go to:
http://localhost:8000

Because the book1 is now served over HTTP, the browser treats it as a
normal website. All relative links, images, CSS, and subpages work
correctly. This bypasses SAF and restores normal filesystem behavior.

Result:
The entire HTML book named book1 displays perfectly on Android while
remaining in the user's own custom directory (/0000) so that it can
be copied over during backups along with the rest of the users' data.

AFAIK, this method works reliably on all modern Android versions.
--
There is always a solution if you stick to your Linux principles.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

The entire HTML book named book1 displays perfectly on Android while remaining in the user's own custom directory (/0000) so that it can
be copied over during backups along with the rest of the users' data.

Having spent formative decades in the Unix world, I always place all of my personal data, tools and documents inside a single top-level directory such
as /usr/local so that everything important is stored in one clean,
predictable location.

But Android 10+ hates us putting our files were we want to put them.
Android wants us to put files where some programmer felt they should be.

A programmer who likely never once set up a Unix or Windows system.
But I've set up many, and I didn't want to compromise on principles.

So by using the POSIX method previously described, I avoided scattering
files across multiple system-managed folders and I kept backups simple
because the entire hierarchy can be copied as one unit.

On Linux and on Windows, I keep all user data in my own custom hierarchy.

I follow the same philosophy on Android by using /0000 as my personal data root. All of my books, manuals, notes and tools live under /0000 so I can
back up everything I care about without hunting through Android's polluted system folders. <https://i.postimg.cc/hjkVFyqJ/scrcpy07.jpg>

On all my Android systems, /0000 is where I store things I care about on
the internal storage, and /0001 is where I store everything I care about on
the external sdcard (where, Android pollutes both cards similarly, so the
mere presence of either /0000 or /0001 tells me instantly where I am.
<https://i.postimg.cc/bNGTzR6q/sdcard1.jpg>

I did not want to compromise my Linux principles by storing my HTML books partly in Download or Documents and partly in /0000, because that breaks
the simplicity and reliability of having one unified directory tree.

Keeping everything in /0000 preserves the same organizational clarity that Linux users get from /usr/local, and it ensures that my data remains
portable, predictable, and easy to manage. <https://i.postimg.cc/BQyRxCN9/webdav11.jpg>

It's shocking to me how long this took to solve without compromising my principles on keeping all user data in a /usr/local like single folder.

Android is getting less & less like Linux, and more & more like iOS.
The beauty of this POSIX solution is that Termux is allowed to use real filesystem calls, so it sees the real directory structure on Android.

Luckily, Termux can access the real filesystem directly using standard Unix system calls, without Android rewriting the paths into SAF content:// URIs. Because Termux sees the actual directory structure, it can serve the HTML manual correctly, and all relative links work.

Those are anti-POSIX layers Android added starting in Android 10
a. SAF (Storage Access Framework)
b. content:// URIs
c. virtual document handles
d. rewritten paths
e. permission intermediaries
f. Android WebView restrictions

In my test case, the HTML books rely on relative links, like:
pages/2.html
images/foo.png
css/style.css

Tens of thousands of them, so changing the links wasn't feasible.
Relative links only work if the browser knows the real directory.

SAF does not.
Android browsers receive SAF URIs like: content://com.android.externalstorage.documents/document/primary%3A0000%2Fbooks%2Fbook1%2Findex.html

These are not POSIX paths, so relative links break.
Termux, however, sees the real POSIX path:
/storage/emulated/0/0000/books/book1

In summary, the principels we learned decades ago setting up Unix and
Windows systems, can still be leveraged to setting up our Android phones.
--
When things get tough, the Linux principles you learned get you through.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

the relative link
pages/2.html
Becomes
content://com.android.externalstorage.documents/document/pages/2.html
which is not a real path. It's a virtual document reference.

I remember that issue (we were replicating hundreds of safety documents
down to a fire engine, but then android didn't like opening shortcuts as file:// URLs

The answer in our case was to install a web server and open them as http://localhost URLs
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again.
I carved out a sane workflow inside an OS that keeps trying to turn into
iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!)

Windows and Linux can easily open HTML books stored in custom top-level hierarchies, even if the books contain tens of thousands of pages & jpegs.

Unfortunately, Android 10 through 16 cannot open HTML book stored in custom top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them
with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as
an intermediary to transform to something else.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again. >>> I carved out a sane workflow inside an OS that keeps trying to turn into >>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy. >>

SUMMARY (Linux users added because it was Linux to the rescue this time!)

Windows and Linux can easily open HTML books stored in custom top-level
hierarchies, even if the books contain tens of thousands of pages & jpegs. >>
Unfortunately, Android 10 through 16 cannot open HTML book stored in custom >> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them
with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as
an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation
--
Remove numerics from my email address.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Dave Royal wrote:

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them
with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as
an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation

Hi Carlos & Dave,

It's a great question, and I apologize for not having explained better.

Thank you for asking, as Android not being Linux hit me by surprise, since
I was shocked that I couldn't just open an HTML folder on Android 16, just
as I opened that same HTML file hierarchy on Windows (& Linux would work).

What floored me is how NOT-LIKE-LINUX Android has become since Android 10.
In terms of being able to use POSIX paths, this new SAF stuff is atrocious.

With SAF, the file system access is nothing like that of Linux or Windows.
With POSIX, the file system is exactly like that of Linux and Windows.

Much like iOS limits almost everything you want to do for efficiency, this
SAF stuff limits what you can do with scripts running on the desktop PC.

Yet, Android "used to be" like Linux in terms of how it accessed files.
That is no more the case.

As for the folder contents, I agree that a lot of books are ebooks, and as
you are well aware, I have scripts that turn almost any electronic book (whether it's epub, text, pdf, MS word, etc.) into mpeg "talking books".

But like it or not, the book I found online is huge repair manual, which
turns out to be extremely hierarchical & extremely terse in text and yet extremely filled with exploded images, interspersed in & out with the text.

For whatever reason, that repair manual is supplied as a single 500MB zip
file containing tens of thousands of images interspersed with html files.

Since it's a repair file, I can't drag the desktop (or even a laptop) under
the vehicle as I do the repair, so I put it on one of my tablets to use it.

I have plenty of iPads but only one Android tablet, so I put it on the
Android 16 tablet thinking it would be worlds easier than doing it on iOS.

It turned out that Android nowadays, is becoming more and more horrific
like iOS already is, in terms of NOT using POSIX file specifications.

What happened to me, yesterday, proves that even though Android's
underlying Linux kernel is POSIX compliant, Android 10+ is decidedly not.
--
Every time I try to automate a desktop with a mobile device, I learn how
much they try to fight us so that they can maintain control of our files.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Andy Burns wrote:

Maria Sophia wrote:

Data =
content://com.android.externalstorage.documents/document/pages/2.html
Yikes. What's happening? This isn't a real file-system path at all.
It's an SAF document URI.

The index.html is written using normal standard relative links such as
pages/2.html
images/foo.png
css/style.css

These only work if the browser knows the real directory.
But the fashuganeh Android SAF apparently hides the directory.

Therefore, SAF URIs cannot be used for relative links inside HTML files.
So when the HTML says: <a href="pages/2.html">
Android tries to resolve it relative to the SAF URI, not the filesystem.

Worse, when I tap an HTML file in ZArchiver, it passes the file using
content://ru.zdevs.zarchiver.external/...
Which is ZArchiver's own SAF wrapper, not a real path.

When I paste the full URI into Privacy Browser, I get the error
Webpage not available.
The webpage at file:///storage/emulated/0/0000/book/name/index.html
could not be loaded because: net::ERR_ACCESS_DENIED

The normal HTML manual expects a real filesystem:
/storage/emulated/0/0000/book/name/index.html
/storage/emulated/0/0000/book/name/pages/2.html
But Android 16 rewrites everything into SAF URIs:
content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html

This means the relative link
pages/2.html
Becomes
content://com.android.externalstorage.documents/document/pages/2.html
which is not a real path. It's a virtual document reference.

So why did file:///storage/emulated/0/0000/book/name/index.html fail?
Android 10+ treats any custom top-level folder as restricted.

Apparently, Android only allows browsers to read:
/storage/emulated/0/Download/
/storage/emulated/0/Documents/
/storage/emulated/0/DCIM/
/storage/emulated/0/Pictures/

Apparently, Occam's Razor says the simplest explanation that fits the facts
is that Android 16 blocks browsers from reading custom top-level folders.

I remember that issue (we were replicating hundreds of safety documents
down to a fire engine, but then android didn't like opening shortcuts as file:// URLs

The answer in our case was to install a web server and open them as http://localhost URLs

Hi Andy,

THANK YOU for confirming the diagnosis and agreeing with the workaround.

Having always dealt with huge HTML references on the desktop, I was wholly unprepared for the shock that Android 10+ is no longer POSIX compliant.

In terms of WebView, Android 10+ is apparently only POXIX compliant in
a. /storage/emulated/0/Download/
b. /storage/emulated/0/Documents/
c. /storage/emulated/0/DCIM/
d. /storage/emulated/0/Pictures/

I "could" have solved the problem by putting the repair manual in one of
those directories, but they're thoroughly polluted much like similar directories are on Windows, so my linux-learned rule is to use /usr/local instead (e.g., on Windows it's c:\data & on Android it's /0000 or /0001).

Android 10+ was trying to force me away from putting everything I care
about into a single top-level folder on each sdcard (/0000 or /0001).

But that makes backup and recovery more complicated since then I would have
to remember where Android forced me to put stuff, and worse, I'd have to maintain those Android hierarchies in a clean way when you know that any directory that is considered "public" on Windows or Android is polluted
beyond belief. So we'd be maintaining and cleaning those folders forever.

I like POSIX.
Hence, I hate SAF.

Reassuringly, your experience stated above matches exactly what I ran into.

The underlying problem seems to be that Android 10+ no longer exposes real POSIX filesystem paths to WebView-based browsers outside of the four
"public" SAF-sanctioned directories (Download, Documents, DCIM, Pictures)/

As of Android 10+, apparently anywhere other than those four highly
polluted folders is treated as a restricted namespace to WebView clients.

When an HTML file is opened from a custom top-level directory such as:
/storage/emulated/0/0000/book/name/index.html
Android does NOT hand the browser the actual POSIX path. Instead, it
rewrites the path into a Storage Access Framework (SAF) content URI.

content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html
But this is not a real directory. It is a virtual document handle.

What you & I both found out was that because the browser never receives the true filesystem location, all relative links inside the manual break.

A link like:
pages/2.html
gets resolved relative to the SAF URI, producing:
content://com.android.externalstorage.documents/document/pages/2.html
which does not correspond to any real file on disk.

As a result, our first indication of the problem is that WebView then
throws ERR_ACCESS_DENIED or ERR_FILE_NOT_FOUND because it cannot traverse
the directory tree. The browser is effectively sandboxed inside a synthetic document namespace with no ability to follow POSIX-style relative paths.

This is why unzipping the manual worked fine, but opening index.html fails
in every browser tested. Yet, it worked perfectly on Windows (& Linux).

So I knew there was nothing wrong with the document's contents, per se.

The HTML book expects a normal Unix-style directory hierarchy, so I was confused until it dawned upon me belatedly that Android's new SAF layer
hides that hierarchy behind virtual URIs (much as iOS does to everything).

While I started off trying to find an ancient browser that would respect
POSIX paths, it turned out that both our solutions seem to be apropos.

I'm embarrassed to say that it took me over an hour or two to figure out
that the solution was to bypass WebView's file:// restrictions entirely by serving the manual over HTTP.

Had I known what you already knew, it wouldn't have taken me a couple of
hours to figure out what hte problem was and what a likely solution is.

That's one of the beauties of Usenet, by the way, in that now everyone
reading this will save the couple of hours it took for me to understand the problem and to implement a solution.
(BTW, I'm curious how long it took your team to figure this one out too!)

With the solution your team and I came up with, HTTP requests do not go
through SAF, so the browser can finally see the real directory structure.

I had no idea what the best server would be, so my implementation was to
grant Termux full filesystem access, and then start a local web server:
$ pkg install python
$ cd /storage/emulated/0/0000/book/name
$ python3 -m http.server 8000

This sets the $DOCUMENT_ROOT, so that on any web browser, I opened:
<http://localhost:8000>

At that point everything worked perfectly. All relative links, images, CSS,
and subpages loaded exactly as intended because the browser was now talking
to a real POSIX-backed directory via HTTP instead of a SAF virtual document tree.

In short, the summary for everyone else to benefit from, that you and I
learned the hard way, is that Android 10+ broke POSIX direct file:// access
for custom top-level directories, but, a workaround is a localhost HTTP
server restores normal Unix semantics. Linux to the rescue, once again.

Thanks again for confirming the approach I ended up with last night.
Had I waited a day, I would have solved it today with your kind advice!

May I ask how long it took you and your team to arrive at that conclusion
and more importantly, what server mechanism you employed, if it's a free ad free easily available web server, because the Termux method has issues too.
--
Usenet allows kind intelligent good-hearted people to help each other out.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-05 15:48, Dave Royal wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again. >>>> I carved out a sane workflow inside an OS that keeps trying to turn into >>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!) >>>
Windows and Linux can easily open HTML books stored in custom top-level
hierarchies, even if the books contain tens of thousands of pages & jpegs. >>>
Unfortunately, Android 10 through 16 cannot open HTML book stored in custom >>> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them
with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as
an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation

Ok...

Heh, they charge 45$ for the epub version.

No ZIP that I can see :-?

I would have to download using wget, and this tool modifies the links so
that they are correct for your local installation.

I wonder if Calibre can convert that to epub.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia wrote:

May I ask how long it took you and your team to arrive at that conclusion
and more importantly, what server mechanism you employed, if it's a free ad free easily available web server, because the Termux method has issues too.

Spent a few hours trying to create working content:// URLs, but when
that didn't work out, used AWebServer, an android build of apache httpd
with a minimal GUI ...

<https://play.google.com/store/apps/details?id=com.sylkat.apache>

In the end we paid the developer to produce a custom build that
1) auto started the web server
and 2) let us set our own document root

It looks like the latest version has included ftp, mySQL and myPHPadmin
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

In comp.mobile.android,alt.os.linux,alt.comp.os.windows-10 "Carlos E. R." <robin_listas@es.invalid> wrote:

On 2026-07-05 15:48, Dave Royal wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again. >>>>> I carved out a sane workflow inside an OS that keeps trying to turn into >>>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!) >>>>
Windows and Linux can easily open HTML books stored in custom top-level >>>> hierarchies, even if the books contain tens of thousands of pages & jpegs. >>>>
Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them
with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as >>> an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation

Ok...

Heh, they charge 45$ for the epub version.

No ZIP that I can see :-?

I would have to download using wget, and this tool modifies the links so that they are correct for your local installation.

I wonder if Calibre can convert that to epub.

As I posted about in (rec.autos.tech) last month:
Subject: Free Vehicle Service Manuals
Date: 11 Jun 2026
Message-ID: <6a2a43e6@news.ausics.net>

I've been using Operation CHARM for some time (https://charm.li/),
which covers vehicles (USA & Canada models) from 1982 to 2013. Now I
see there's a new site, LEMON, with service manuals for vehicles
from 1960 to 2025:

https://lemon-manuals.la/
--
__ __
#_ < |\| |< _#
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-05 18:38, Maria Sophia wrote:

Andy Burns wrote:

Maria Sophia wrote:

...

Hi Andy,

THANK YOU for confirming the diagnosis and agreeing with the workaround.

Having always dealt with huge HTML references on the desktop, I was wholly unprepared for the shock that Android 10+ is no longer POSIX compliant.

In terms of WebView, Android 10+ is apparently only POXIX compliant in
a. /storage/emulated/0/Download/
b. /storage/emulated/0/Documents/
c. /storage/emulated/0/DCIM/
d. /storage/emulated/0/Pictures/

I "could" have solved the problem by putting the repair manual in one of those directories, but they're thoroughly polluted much like similar directories are on Windows, so my linux-learned rule is to use /usr/local instead (e.g., on Windows it's c:\data & on Android it's /0000 or /0001).

Why not /storage/emulated/0/Documents/Books ?

I have {external card}/Movies to store movies in my new tablet and it
works fine with VLC. I also have {external card}/eBooks, but I need yet
a reader (Calibre is not available that I can find).

I just installed "Librera" from F-droid. It doesn't see the books in
that folder, even though it asked for permission to see all files. It sees:

/storage/emulated/0/Android
/storage/emulated/0/Download
/storage/emulated/0/Librera

However, if I browse to:

/storage/emulated/0/eBooks using cX file exprorer, and tap on a book, it offers me to upload to "Play Libros" (maybe Play Books?) or use "Librera
FD", and the later works.

It seems that browsing and opening with CX, apps inherits the permission
in runtime to open that file.



I don't like storing a multithousand file thing in a card that is
possibly FAT or eFAT. Too many writes to the FAT area.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Andy Burns wrote:

Maria Sophia wrote:

May I ask how long it took you and your team to arrive at that conclusion
and more importantly, what server mechanism you employed, if it's a free ad >> free easily available web server, because the Termux method has issues too.

Spent a few hours trying to create working content:// URLs, but when
that didn't work out, used AWebServer, an android build of apache httpd
with a minimal GUI ...

<https://play.google.com/store/apps/details?id=com.sylkat.apache>

In the end we paid the developer to produce a custom build that
1) auto started the web server
and 2) let us set our own document root

It looks like the latest version has included ftp, mySQL and myPHPadmin

Hi Andy,\

Thank you for your kind and detailed reply, as Usenet is to not only ask questions, but to also help everyone lurking not make our same mistakes.

When Android dropped POSIX, Linux again saved the day with localhost HTTP!

It was a painful time-consuming lesson for me, but mainly because I had
trusted that Android was Linux-like when it came to the basic POSIX paths.

Your answer will help save others countless hours of debugging time.
And your answer helps me determine if I should invest in testing it out.

I like what the content of says about how it can help all of us carry on
our mobile devices custom HTML content containing relative filespec paths.
<https://play.google.com/store/apps/details?id=com.sylkat.apache>
AWebServer: Apache,PHP,SQL,SSH
You can explore the files with any SO or browser through wireless.
AWebServer is an easy and friendly solution to publish your own web in
your Android device with PHP and all the features that Apache brings.
MariaDb the old Mysql sql server is also included and the MyPhpAdmin
application has been installed and ready to work with.
Has integrated a FTP server to upload the contents and is compatible with
The Web Server is ready to use and has these features:
+Apache 2, +Php 7, +MariaDb, +MyPhpAdmin, +Indexes Options, +Ftp server,
+Logs viewer, +Text Editor.
This app is based on the famous and stable Apache 2 server, known by its
stability in Android devices. Any question or feature request,
please send a mail to the developer kryzoxy@gmail.com

It seems your description of how your team solved the non-POSIX problem
aligns pretty much with what I observed. Unfortunately for those of us who
want to use POSIX-compliant paths in documentation, Android 10+
fundamentally changed how applications are allowed to access shared
storage. Anything that is not one of the four SAF-approved public
collections (Download, Documents, DCIM, Pictures) is no longer exposed to WebView as a real POSIX path.

Instead, WebView receives a synthetic SAF content URI such as: content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html
But this is not a directory. It is a virtual document handle.

We learned the hard what that, because WebView never receives the actual filesystem path, it cannot perform POSIX operations such as open(), stat(),
or opendir() on the underlying directory tree. As a result, any HTML manual that relies on normal relative links (pages/2.html, images/foo.png, css/style.css) immediately breaks. Every browser attempt to resolve these
links relative to the SAF URI inevitably produces invalid paths such as: content://com.android.externalstorage.documents/document/pages/2.html
which, we found out the hard way, do not correspond to any file on disk.

WebView then throws ERR_ACCESS_DENIED or ERR_FILE_NOT_FOUND which we have
to debug is only because the browser cannot traverse the non-POSIX
directory hierarchy. In effect, the browser appears to be sandboxed inside
a synthetic namespace with no ability to follow POSIX-style relative paths.

This hypothesis may explain why the manual opened perfectly on Windows (and would have opened on Linux too), but failed on Android 16 in any browser.

The HTML book expects a normal Unix directory structure, but Android 10+
hides that structure behind SAF, much like iOS hides their file specs too.

Since I only came up with the idea last night after a couple of hours of debugging, it's helpful to note that your team's solution and mine converge
on the same principle, which is to bypass WebView's file:// restrictions entirely by serving the manual over HTTP.

The reason this works is that HTTP requests do not go through SAF, so the browser finally sees the real directory tree.

In your case, you used AWebServer (an Android build of Apache httpd).
In my case, I used Termux with Python's built-in HTTP server:
$ pkg install python
Manually give Python storage access permissions as it doesn't ask.
Then set the $DOCUMENT_ROOT by starting the server at the top level
$ cd /storage/emulated/0/0000/book/name
$ python3 -m http.server 8000

Then, in any privacy-based web browser, I simply set this bookmark:
<http://localhost:8000>

At that point everything worked exactly as intended. All relative links, images, CSS, and subpages loaded correctly because the browser was now
talking to a real POSIX-backed directory via HTTP instead of a SAF virtual document tree.

Comparing the two approaches, your solution is far better'n mine is:
a. You have a full Apache httpd stack
b. Your solution has nice GUI controls
c. Your solution can auto-start
d. Your solution has a customizable document root
Hence, your solution works in production or institutional deployments.

Compared to mine, your solution is heavyweight but robust as all hell.
I can see why it's good for fire engines, kiosks & embedded deployments
And your solution supports additional services (FTP, MySQL, PHP) if needed

By way of stark contrast, the solution I came up with (Termux + Python):
a. Is as lightweight as I could make it
b. With almost zero configuration (other than the starting directory)
c. Yet, like yours, it creates a pure POSIX environment
d. Which is good for my Windows/Linux-style adb-scripted workflows

Unfortunately, my solution has none of the GUI, auto-start & service
management of your solution, but it has a minimal attack surface and it's
easy to script and automate if I wish, so it's OK for ad hoc servers.

The takeaway for the team to learn from our trials and tribulations is that both approaches solve the same underlying problem that Android 10+ broke
direct POSIX file:// access for custom top-level directories.

Luckily, our solution of localhost HTTP restores normal Unix semantics.

In summary, for those wishing to learn from our investment in testing,
Android browsers cannot directly open HTML manuals from custom directories anymore because SAF hides the real filesystem.

Luckily, a localhost HTTP server bypasses SAF to restore POSIX behavior.

Your team's experience confirms the diagnosis and validates the workaround.
I appreciate you sharing the details, especially the fact that you
eventually commissioned a custom build of AWebServer to auto-start and set
the document root. That is extremely useful information for anyone out
there who is deploying large HTML documentation sets in the field.

Thanks again for the insight. This thread will save others the hours we
both invested in rediscovering the same SAF limitations independently.
--
POSIX paths died on Android 10+, but localhost HTTP brings them back!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote:

In terms of WebView, Android 10+ is apparently only POXIX compliant in
a. /storage/emulated/0/Download/
b. /storage/emulated/0/Documents/
c. /storage/emulated/0/DCIM/
d. /storage/emulated/0/Pictures/

I "could" have solved the problem by putting the repair manual in one of
those directories, but they're thoroughly polluted much like similar
directories are on Windows, so my linux-learned rule is to use /usr/local
instead (e.g., on Windows it's c:\data & on Android it's /0000 or /0001).

Why not /storage/emulated/0/Documents/Books ?

I have {external card}/Movies to store movies in my new tablet and it
works fine with VLC. I also have {external card}/eBooks, but I need yet
a reader (Calibre is not available that I can find).

I just installed "Librera" from F-droid. It doesn't see the books in
that folder, even though it asked for permission to see all files. It sees:

/storage/emulated/0/Android
/storage/emulated/0/Download
/storage/emulated/0/Librera

However, if I browse to:
/storage/emulated/0/eBooks using cX file exprorer, and tap on a book, it offers me to upload to "Play Libros" (maybe Play Books?) or use "Librera FD", and the later works.

It seems that browsing and opening with CX, apps inherits the permission
in runtime to open that file.
I don't like storing a multithousand file thing in a card that is
possibly FAT or eFAT. Too many writes to the FAT area.

Hi Carlos,

Thanks for asking as I would agree 9999 out of 10K people would just do whatever the mothership tells them to do, in terms of storing files.

Microsoft tells us to put everything in the polluted directories too.

Having cut my teeth in the 60s, 70's, 80's and 90's days of computers...
a. I put my menus in C:\data\menus (which is not polluted by installers).
b. I put my temp files in C:\tmp (again, which isn't polluted by others).
c. And I put my data in C:\data (which is not polluted by any programs).
etc.
I never need to use search because I know where all my files reside.
And I can back up all that I care about by backing up one directory.

On Windows or Linux, programs like Calibre (which, I agree, is one of the finest document conversion utilities on the planet), find all the files.

But, on Android 10+, the mothership decided to ditch POSIX paths in part.

Given all that, I understand why you suggested that I jut put my data in /storage/emulated/0/Documents/Books, but the reason I do not use that (and hopefully I never will) comes directly from my decades of Unix system administration. On every Unix I have ever worked with, whether that's
SunOS, Solaris, Ultrix, DEC, VAX, AIX, HP-UX, IRIX, BSD, and even IBM
mainframe Unix subsystems, we always kept a strict separation between
a. system-managed directories
b. user-managed directories

In fact, as I see it, the entire point of usr/local was to give the administrator a clean, unpolluted, non-system-owned hierarchy where nothing
is ever overwritten, reorganized, or repurposed by the OS. Like /opt, it is
one place where you can put your own tools, your own data, your own
archives, and know that the operating system will likely never touch it.

Much like anything in Window's public menu & data folders, Android's "Documents", "Download", "DCIM", "Pictures", etc., are the exact opposite.

They are system-owned, system-polluted, and system-repurposed.

As a result of being public refuse garbage pails, they accumulate all sorts
of junk from apps, thumbnails, metadata, temporary files, cloud sync
artifacts and anything else the OS or apps decide to dump there. They are
not stable, not predictable and not safe for long-term archival storage.

To back up completely everything I care about on Android, is this simple:
adb pull /storage/emulated/0/0000 C:\data\datedbackup\0000 (internal sd)
adb pull /storage/XXXX-XXXX/0001 C:\data\datedbackup\0001 (external sd)

If I start putting files willy nilly all over Android, I'll be just like
the average hoi polloi proletariat who can't find anything on their
devices, and worse, who complain like hell when the system needs a backup.

I know you're well meaning, but in effect your suggestion is equivalent to
me as it would be for me to tell a Unix admin to store their personal tools
and archives inside /usr/bin or /var/tmp simply because "the OS can see
it." I know you're a Linux owner, but that's just not how I do things.

To back up completely everything I care about on Windows, is this simple:
robocopy C:\data D:\data-backup /MIR /R:1 /W:1 /XJ

My directory philosophy is simple:
I always create one top-level directory that is mine and only mine,
and I put everything I care about inside it (if at all possible).
a. On Linux, that is /usr/local.
b. On Windows, that is c:\data.
c. On Android, that is /0000 (internal) and /0001 (external).

This gives me:
a. a single hierarchy to back up
b. a single hierarchy to restore
c. a single hierarchy that never gets polluted
d. a single hierarchy that never changes names or semantics
e. a single hierarchy that is not touched by the OS
f. a single hierarchy that behaves like a real Unix directory tree Unfortunately, Android's SAF filespecs do not meet any of those criteria.

Your own example actually seems to aptly demonstrates the problem where
Librera cannot even see your eBooks directory unless you open files through
CX File Explorer. That is because SAF grants per-file access tokens, not directory access. CX hands Librera a one-file token, so Librera can open
that single file but still cannot enumerate the directory.

This is exactly the same SAF behavior that broke my HTML manuals.

Regarding your FAT/exFAT concern, you are absolutely correct that FAT-based
SD cards can suffer from excessive FAT table rewrites when storing large directory trees. A directory containing tens of thousands of HTML pages and JPEGs will hammer the FAT metadata area. Fortunately, my Android 16 tablet
has no SD card as it was a return to me of a gift I gave an iOS user to try
to convince them that their religion was wrong, so, my files in /0000 are
in ext4-backed internal storage with journaling & proper metadata handling.

So I fit your concern as it's safe for large POSIX-style directory trees.

This brings us back to the core issue Andy and I both hit, which is that Android 10+ no longer exposes real POSIX filesystem paths to WebView-based browsers outside the SAF-approved yet highly polluted public collections.

Anything else is rewritten into a synthetic SAF URI such as:
content://com.android.externalstorage.documents/document/primary%3A0000%2Fbook%2Fname%2Findex.html
This is not a directory. It is a virtual document reference.

Because WebView never receives the actual filesystem path, it cannot
perform POSIX operations such as open(), stat(), or opendir() on the
underlying tree. As a result, any HTML manual that relies on normal
relative links (pages/2.html, images/foo.png, css/style.css) immediately breaks. Every browser that I tried last night tried to resolve those links relative to the SAF URI, producing invalid paths like:
content://com.android.externalstorage.documents/document/pages/2.html
which do not correspond to any real file on disk. WebView then throws ERR_ACCESS_DENIED or ERR_FILE_NOT_FOUND because it cannot traverse the directory hierarchy.

This explains why the manual opens perfectly on Linux and Windows, but
fails on Android. The HTML book expects a normal Unix directory structure,
but Android 10+ hides that structure behind SAF, much like iOS does.

Andy's team and I independently arrived at the same workaround, which was
to explicitly bypass WebView's file:// restrictions entirely by serving the manual over HTTP since HTTP requests do not go through SAF, so the browser finally sees the real directory tree.

Andy used AWebServer (Apache httpd for Android).
I used Termux + Python but accomplished, essentially, the same effect.

So the summary for everyone on Usenet is:

Android browsers cannot open HTML manuals from custom directories because
SAF hides the real filesystem. A localhost HTTP server bypasses SAF and restores normal POSIX behavior.

And the summary for your kind and quite naturally normal question is:

I do not use Documents/Books for the same reason I do not use /usr/bin on Linux, as it is not my directory, it is not clean, and it is not stable.

And, I appreciate your FAT/exFAT concern, which is valid for SD cards, but
my internal storage is ext4, so /0000 happens to be in internal storage.

You are hitting the *same* problem Andy and I hit, which is that Librera
cannot see /storage/emulated/0/eBooks, but if CX File Explorer opens a
file, Librera can read that one file. These are all SAF behaviors, and not Librera behaviors, not Calibre behaviors, nor EPUB behaviors.

So, to solve your problem, even though HTTP bypasses SAF completely, the question of whether it solves your specific workflow depends on whether the apps in your specific workflow can open HTTP URLs. Can they?
--
Unfortunately SAF blocks file:// but luckily, HTTP bypasses it completely. --- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 15:48, Dave Royal wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again. >>>>> I carved out a sane workflow inside an OS that keeps trying to turn into >>>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!) >>>>
Windows and Linux can easily open HTML books stored in custom top-level >>>> hierarchies, even if the books contain tens of thousands of pages & jpegs. >>>>
Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them
with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as >>> an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation

Ok...

Heh, they charge 45$ for the epub version.

No ZIP that I can see :-?

I would have to download using wget, and this tool modifies the links so that they are correct for your local installation.

The links are normally relative to the document root, so no need
to modify them.

In the days when software was released on CD such html documentation was common. But any browser could read local http files then.

I wonder if Calibre can convert that to epub.

If so I suppose you'd have to specify the medium size - eg A4. An
html file is liquid - it fills any window or page size.
--
Remove numerics from my email address.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-05 22:00, Dave Royal wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 15:48, Dave Royal wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again.
I carved out a sane workflow inside an OS that keeps trying to turn into >>>>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!) >>>>>
Windows and Linux can easily open HTML books stored in custom top-level >>>>> hierarchies, even if the books contain tens of thousands of pages & jpegs.

Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
top-level POSIX folders such as /storage/emulated/0/0000/books/book1/. >>>>

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them >>>> with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as >>>> an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation

Ok...

Heh, they charge 45$ for the epub version.

No ZIP that I can see :-?

I would have to download using wget, and this tool modifies the links so
that they are correct for your local installation.

The links are normally relative to the document root, so no need
to modify them.

In the days when software was released on CD such html documentation was common. But any browser could read local http files then.

Yes, I know. But calling that "book" confused me.

I wonder if Calibre can convert that to epub.

If so I suppose you'd have to specify the medium size - eg A4. An
html file is liquid - it fills any window or page size.

Epub is also liquid. PDF is not.


I did a quick test. I downloaded that "book":

wget --mirror --convert-links --adjust-extension --page-requisites --no-parent -nH https://doc.rust-lang.org/stable/book/

Then told Calibre to import it, then to convert to epub, which it did.

cer@Laicolasse:~/Documents/Calibre Library/Unknown/The Rust Programming Language - The Rust Programming Language (80)> l
total 5512
drwxr-xr-x 2 cer users 155 Jul 5 22:38 ./
drwxr-xr-x 5 cer users 150 Jul 5 22:36 ../
-rw-r--r-- 1 cer users 1114 Jul 5 22:39 metadata.opf
-rw-r--r-- 1 cer users 3025227 Jul 5 22:38 The Rust Programming Language - The Rust P - Unknown.epub
-rw-r--r-- 1 cer users 2610606 Jul 5 22:36 The Rust Programming Language - The Rust P - Unknown.zip
cer@Laicolasse:~/Documents/Calibre Library/Unknown/The Rust Programming Language - The Rust Programming Language (80)>


Of course, it is up for someone interested in whatever book to actually tailor the conversion to his convenience. In my test, it seems to stop at chapter 3 for some reason. Surely someone has done this before and there is documentation somewhere.

Calibre is also capable of viewing the ZIP file directly, but it calls firefox to do the actual viewing.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-05 20:54, Maria Sophia wrote:

But, on Android 10+, the mothership decided to ditch POSIX paths in part.

Given all that, I understand why you suggested that I jut put my data in /storage/emulated/0/Documents/Books, but the reason I do not use that (and hopefully I never will) comes directly from my decades of Unix system administration. On every Unix I have ever worked with, whether that's
SunOS, Solaris, Ultrix, DEC, VAX, AIX, HP-UX, IRIX, BSD, and even IBM mainframe Unix subsystems, we always kept a strict separation between
a. system-managed directories
b. user-managed directories

I have my ways in Linux, but when I use a different OS, like Android, I
adapt to its ways. I don't try to enforce my older habits ;-)

I did a test, downloading that rust book to my tablet, into

/storage/emulated/0/Documents/rust/book

and then tried to point firefox to it. Did not work. Then I navigated to
the "index" in CX, and tapped on it. It asked what to use, I said FFx,
and it happily opened the "book".

It is pointing to http://127.0.0.1:26108/sdcard/0/storage/6130-3634/Documents/book/index.html

I guess CX created automatically a web server on the fly, which is a
neat trick. Nice app.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Dave Royal wrote:

No ZIP that I can see :-?

I would have to download using wget, and this tool modifies the links so
that they are correct for your local installation.

The links are normally relative to the document root, so no need
to modify them.

In the days when software was released on CD such html documentation was common. But any browser could read local http files then.

I wonder if Calibre can convert that to epub.

If so I suppose you'd have to specify the medium size - eg A4. An
html file is liquid - it fills any window or page size.

As Dave Royal noted to Carlos, all paths are relative to $DOCUMENT_ROOT.

Also, as Dave noted, EPUB is essentially a packaged, standardized container built decades later on top of XHTML and CSS, long after HTML documentation
was already widespread in CD ROM supplied documentation and help systems.

Looking up Carlos' Calibre question, apparently Calibre can convert a
complex multi-file HTML book into a single EPUB/AZW3 file, as long as we
give it the entire directory (usually as a ZIP) if it is formatted well.
1. Feed the ZIP to Calibre,
2. Convert to EPUB,
3. Output a single, portable book with all images and subfiles embedded.

Once Calibre converts the zip to an epub, it can be copied to Android.
--
Usenet allows good friends around the world to discuss their experiences.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote:

I have my ways in Linux, but when I use a different OS, like Android, I adapt to its ways. I don't try to enforce my older habits ;-)

I did a test, downloading that rust book to my tablet, into

/storage/emulated/0/Documents/rust/book

and then tried to point firefox to it. Did not work. Then I navigated to
the "index" in CX, and tapped on it. It asked what to use, I said FFx,
and it happily opened the "book".

It is pointing to http://127.0.0.1:26108/sdcard/0/storage/6130-3634/Documents/book/index.html

I guess CX created automatically a web server on the fly, which is a
neat trick. Nice app.

Hi Carlos,

Yes. I agree. We didn't add the Linux/Windows folks on the original four articles in this series, but the fourth article mentioned your exact trick:

> So I need to find an app that still use direct POSIX filesystem
> access (and ignores SAF entirely), or, I can install a local HTTP
> server in Termux.
> Apparently, these file managers have their own internal HTML renderer
> that bypasses WebView, so I might resort to testing these one by one.
> a. MiXplorer (best option)
> b. X-plore
> c. Older versions of Cx File Explorer
> But I think the most reliable will be to use Termux, which can access
> /0000 directly because it uses POSIX APIs (not SAF) & then start a server.

Had the Python server not worked, I would have tried the method you used.

What I find useful and interesting and even enlightening, is that all three
of us (you, me and Andy) independently came up with the same HTML solution.

The only other solution than an HTML server that I can think of is to make Calibre work to convert the huge multi-file zip into a single epub file.

Since Calibre can do almost anything, as it's one of the best programs on
this planet for converting anything to anything else, I'll test that out.
--
Every post to Usenet should strive to add value that wasn't there before.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote:

Calibre is also capable of viewing the ZIP file directly,
but it calls firefox to do the actual viewing.

Hi Carlos,

I fed my 500MB zip file into Calibre and told it to convert it to an EPUB, which took a few hours on my 2009 Windows 10 PC, but it worked beautifully.

The resulting EPUB file was 400MB so it took a while for Calibre to load it
the first time (due to all the caching that Calibre does on first loading).

When I looked at the file inside of Thorium, I got an appreciation for why
HTML is an excellent medium, as there were tens of thousands of connected
pages and images, where an EPUB can handle it, but it's slow as all hell.

Since the EPUB itself was 400MB, I didn't even bother copying to Android.
If it's slow on Windows, it's likely gonna be even slower on Android.

The HTML is, by way of contrast, is virtually instant when clicking about.

When I tried to convert the EPUB to a PDF, Calibre failed (with what seemed like memory errors) after about an hour or two, so I gave up on the PDF.

Looking into my c:\app\editor\epub directory, these seem to be most common cross platform EPUB readers, where I've sorted by large file handling.
thorium
most stable & fastest for huge image-heavy epubs like textbooks
calibre
most powerful for conversion & repair of image-heavy epubs
redium desktop
sibling of thorium but less polished than thorium
okular
KDE document viewer with medium-level EPUB support via plugins
hamster
best for small epubs
lucidor
best for very small epubs
fbreader
suitable for smaller epubs
adobe digital editions
not suitable as the epub engine is old and fragile
sumatra pdf
fast for small epubs

In summary, for certain kinds of references (such as highly cross-linked
highly imaged technical manuals and textbooks), a zip HTML is likely ideal.
--
The best way to learn is to try it and then learn from the mistakes.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 22:00, Dave Royal wrote:

In the days when software was released on CD such html documentation was common. But any browser could read local http files then.

Yes, I know. But calling that "book" confused me.

I wouldn't call it a book either. The rust manual, to which had a
bookmark (!) on this tablet, was the first example I thought of.
It was just fortuitous that it had 'book' in the url. I see this
in the source:
<!-- Book generated using mdBook -->

Epub is also liquid.

I had forgotten. A few years back I converted a 'tunebook' - a mix of musical scores and text - into mobi format for display on a kindle. You want the score to occupy the whole page width, as big as possible. I wasn't sure how mobi resized the images, hence my comment in https://mudcat.org/thread.cfm?threadid=171470#4147314
"I wonder if the mobi has converted the compressed SVGs to some
other image format, each at several sizes for different
Kindles?"
--
Remove numerics from my email address.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-06 07:06, Maria Sophia wrote:

Carlos E. R. wrote:

Calibre is also capable of viewing the ZIP file directly,
but it calls firefox to do the actual viewing.

Hi Carlos,

I fed my 500MB zip file into Calibre and told it to convert it to an EPUB, which took a few hours on my 2009 Windows 10 PC, but it worked beautifully.

Wow. My laptop took a few seconds, but it was just a 2.5 MiB zip.

The resulting EPUB file was 400MB so it took a while for Calibre to load it the first time (due to all the caching that Calibre does on first loading).

I have never seen an epub that big. In my case, the book that I tested
with can be purchased in epub format. Possibly the epub is available on
the emule network or such (for testing, of course).

When I looked at the file inside of Thorium, I got an appreciation for why HTML is an excellent medium, as there were tens of thousands of connected pages and images, where an EPUB can handle it, but it's slow as all hell.

Since the EPUB itself was 400MB, I didn't even bother copying to Android.
If it's slow on Windows, it's likely gonna be even slower on Android.

The HTML is, by way of contrast, is virtually instant when clicking about.

When I tried to convert the EPUB to a PDF, Calibre failed (with what seemed like memory errors) after about an hour or two, so I gave up on the PDF.

I don't like PDF for books, because it doesn't flow the text. It is
fixed size. You need a display that matches the design size and
resolution (or better).

Looking into my c:\app\editor\epub directory, these seem to be most common cross platform EPUB readers, where I've sorted by large file handling.
thorium
most stable & fastest for huge image-heavy epubs like textbooks
calibre
most powerful for conversion & repair of image-heavy epubs
redium desktop
sibling of thorium but less polished than thorium
okular
KDE document viewer with medium-level EPUB support via plugins
hamster
best for small epubs
lucidor
best for very small epubs
fbreader
suitable for smaller epubs
adobe digital editions
not suitable as the epub engine is old and fragile
sumatra pdf
fast for small epubs

In summary, for certain kinds of references (such as highly cross-linked highly imaged technical manuals and textbooks), a zip HTML is likely ideal.

Seeing that calibre imports the html directory as a zip file, it is
possible that there is software out there that directly renders readable
those ZIP files. Or even hardware.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-06 08:58, Dave Royal wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 22:00, Dave Royal wrote:

In the days when software was released on CD such html documentation was common. But any browser could read local http files then.

Yes, I know. But calling that "book" confused me.

I wouldn't call it a book either. The rust manual, to which had a
bookmark (!) on this tablet, was the first example I thought of.
It was just fortuitous that it had 'book' in the url. I see this
in the source:
<!-- Book generated using mdBook -->

Epub is also liquid.

I had forgotten. A few years back I converted a 'tunebook' - a mix of musical scores and text - into mobi format for display on a kindle. You want the score to occupy the whole page width, as big as possible. I wasn't sure how mobi resized the images, hence my comment in https://mudcat.org/thread.cfm?threadid=171470#4147314
"I wonder if the mobi has converted the compressed SVGs to some
other image format, each at several sizes for different
Kindles?"

The kindle doesn't use epub format. They are two competing markets with different software.

The images I have seen on epubs are bitmaps, so hardly "zoomable". I
mean, if the image has more pixels than my ebook device, the image
results hard to read or view.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-06 12:05, Carlos E. R. wrote:

On 2026-07-06 07:06, Maria Sophia wrote:

Carlos E. R. wrote:

In summary, for certain kinds of references (such as highly cross-linked
highly imaged technical manuals and textbooks), a zip HTML is likely
ideal.

Seeing that calibre imports the html directory as a zip file, it is
possible that there is software out there that directly renders readable those ZIP files. Or even hardware.

I asked chatgpt.

Q: I have recently seen "books" transferred as a ZIP archive of a large
html tree. Calibre calls a browser to see a page at a time, AFAIK. I
wonder if there is software that displays that ZIP as a book directly,
better on a tablet.

Yes. What you've seen is often called an **HTMLZ** (HTML in a ZIP), or
simply a ZIP containing a static website. It's a nice format because it preserves hyperlinks, CSS, images, and search indexes while compressing
very well.

The difficulty is that there isn't a universally adopted "book reader"
for zipped HTML trees analogous to EPUB readers.

Here are the main options:

* **Calibre**: as you note, it essentially extracts or serves the HTML
and uses an embedded browser. It isn't really a dedicated HTML book
renderer.

* **KOReader** (Android, Linux, Kobo, Kindle): probably the closest to
what you're looking for. It primarily supports EPUB, PDF, DjVu, etc.,
but it can also browse HTML files. However, it doesn't natively treat an arbitrary ZIPped website as a single book.

* **Static website in a browser**: on Android or Linux you can simply
unzip the archive and open `index.html`. Browsers do a surprisingly good
job. Firefox on Android, for example, can open local HTML files (with a
bit of help from a file manager).

* **Mini HTTP server**: many people run

```bash
python3 -m http.server
```

in the extracted directory and browse to `http://localhost:8000/`.
This avoids issues some browsers have with `file://` URLs and JavaScript.

### Why EPUB became dominant

An EPUB is essentially:

```
book.epub
└── ZIP archive
├── XHTML files
├── CSS
├── images
├── metadata
└── navigation (table of contents)
```

So EPUB is really a standardized HTML tree in a ZIP with metadata.
Readers know how to paginate it, remember your position, annotate,
search, adjust fonts, etc. A raw ZIP of HTML lacks that standard structure.

### If your documentation is generated

For things like Rust docs, Python docs, man-page collections, or API documentation, I would actually **keep them as HTML** rather than
converting to EPUB. Documentation relies on hyperlinks more than on
linear reading, and browsers excel at that.

### An interesting possibility

It wouldn't be hard to write a small application that:

* opens a ZIP without extracting it permanently,
* serves its contents through an embedded HTTP server,
* displays them in a WebView,
* remembers your position and reading history.

Modern ZIP libraries allow random access, so the pages needn't even be unpacked to disk. I'm a little surprised there isn't a well-known
open-source app that does exactly this, because it would be ideal for
offline documentation on a tablet.

Out of curiosity, are you mainly thinking of **technical documentation** (Rust, Python, Linux man pages, etc.), or of **books** distributed as
HTML? The best tool tends to differ between those two use cases.


Q: I was thinking of that rust documentation, but as an example of the
system.

I think the Rust documentation is actually an excellent example because
it's *not* a linear book in the EPUB sense. It's a small self-contained website. That changes what the ideal reader looks like.

If I were designing an offline documentation system today, I'd package
it as:

```
rust-book.zip
├── index.html
├── ch01.html
├── css/
├── fonts/
├── images/
├── search-index.js
└── ...
```

and the "reader" would simply:

* mount or read the ZIP directly;
* expose it through an internal HTTP server (or a custom URL scheme);
* render it in a browser component (WebView, Qt WebEngine, etc.);
* remember the last page, bookmarks, and maybe annotations.

No conversion to EPUB would be necessary.

The nice thing is that all the navigation, CSS, search, and JavaScript
already exist. You'd just be providing a pleasant container around them.

### Existing software gets close

There are a few projects in the same spirit:

* **Zeal** (Linux/Windows) and **Dash** (macOS) store documentation in compressed docsets. Internally, these are HTML trees plus an index
database. They're aimed at API documentation rather than books.
* **DevDocs Offline** projects cache the HTML documentation for offline use.
* Browser-based **Progressive Web Apps** can cache entire documentation
sites for offline use, although support varies.

The common theme is that they're all essentially shipping HTML, not
inventing a new document format.

### Why browsers aren't terrible readers anymore

Twenty years ago, HTML was a poor "book" format because pages were
static and browsers had little support for reading workflows. Nowadays browsers have:

* full-text search,
* history,
* zoom,
* dark mode,
* responsive layout,
* good typography,
* JavaScript-based navigation.

For technical documentation, that's often *better* than an EPUB reader, because the documentation was authored as a website in the first place.

### A feature I'd still like to see

One thing I haven't seen is a generic **"ZIP book reader"**: point it at
any ZIP containing an `index.html`, and it treats it like a book. It
would need only a handful of features:

* open ZIP without extracting it;
* detect the entry page (`index.html`);
* keep reading position;
* bookmarks;
* optional full-text search (using an embedded index if present).

That would cover not only the Rust Book, but also many documentation
bundles, offline manuals, and even archived wikis. It's a surprisingly
simple concept, yet I don't know of a mainstream application dedicated
to it.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote:

I fed my 500MB zip file into Calibre and told it to convert it to an EPUB, >> which took a few hours on my 2009 Windows 10 PC, but it worked beautifully.

Wow. My laptop took a few seconds, but it was just a 2.5 MiB zip.

My desktop is from 2009. It's still working well, but this stressed it. :)

The resulting EPUB file was 400MB so it took a while for Calibre to load it >> the first time (due to all the caching that Calibre does on first loading).

I have never seen an epub that big. In my case, the book that I tested
with can be purchased in epub format. Possibly the epub is available on
the emule network or such (for testing, of course).

My experience had been the same as yours. EPUBs are generally quite small.
This one has tens of thousands of separate images yet very little text.

When I looked at the file inside of Thorium, I got an appreciation for why >> HTML is an excellent medium, as there were tens of thousands of connected
pages and images, where an EPUB can handle it, but it's slow as all hell.

Since the EPUB itself was 400MB, I didn't even bother copying to Android.
If it's slow on Windows, it's likely gonna be even slower on Android.

The HTML is, by way of contrast, is virtually instant when clicking about. >>
When I tried to convert the EPUB to a PDF, Calibre failed (with what seemed >> like memory errors) after about an hour or two, so I gave up on the PDF.

I don't like PDF for books, because it doesn't flow the text. It is
fixed size. You need a display that matches the design size and
resolution (or better).

I agree that PDF isn't all that great for books in that, for me, my eyes
aren't so great and a PDF makes you sit and stare at it to read it.

I prefer to convert the (text) PDF to audio using cross platform balabolka freeware which then turns any (text) PDF into an audio book.

It's not as good as a human reader for some books, e.g., when I converted Einstein's 1916 (updated in 1922) book on relativity, calculations are
messed up when spoken by balabolka's conversion utilities.

But now I'm one of the few non-physicists who understand gravity as a
result, since I was in a compression/decompression chamber for a month.

As an aside, almost nobody understands gravity. One in a million I'd bet.
And even as I understand it to that level, there's still much I don't know.

Looking into my c:\app\editor\epub directory, these seem to be most common >> cross platform EPUB readers, where I've sorted by large file handling.
thorium
most stable & fastest for huge image-heavy epubs like textbooks
calibre
most powerful for conversion & repair of image-heavy epubs
redium desktop
sibling of thorium but less polished than thorium
okular
KDE document viewer with medium-level EPUB support via plugins
hamster
best for small epubs
lucidor
best for very small epubs
fbreader
suitable for smaller epubs
adobe digital editions
not suitable as the epub engine is old and fragile
sumatra pdf
fast for small epubs

In summary, for certain kinds of references (such as highly cross-linked
highly imaged technical manuals and textbooks), a zip HTML is likely ideal.

Seeing that calibre imports the html directory as a zip file, it is
possible that there is software out there that directly renders readable those ZIP files. Or even hardware.

I agree that Calibre had no problem importing the single 500MB zip file.
It just took a long time, but Calibre didn't even blink on the contents.

It's just that my circa 2009 PC runs slowly when it's time to crunch it.

I've learned there's a good reason highly cross-linked documents filled
with images and almost no text are supplied in a zip file HTML format.

It's amazing how fast HTML is compared to the EPUB, although the epub has
the distinct advantage of a fantastic search mechanism that shocked me.

With EPUB, when you search, you get every instance but every line of every instance (much like you'd get with a (text) PDF, so that was really nice.

So if you need to search a huge 500MB HTML document containing tens of thousands of files, converting it to a 400MB EPUB allows that fantastic
search, but if you need to actually navigate it, an HTML server wins out.
--
Converting 400MB EPUBs on a 2009 desktop as HTML loads faster than time.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia, 2026-07-05 00:40:

New-to-me tablet that someone gave back that I had given them as a gift.

I was copying an already-unzippled set of 25,000 html and JPEG files for a book from Windows to an Android tablet but it was taking forever (hours) so
I stopped it and copied only the 500MB zip file in just a minute or two,
but now that it's on Android how do I best unzip it so it works as HTML.

Cx File Explorer can also extract ZIP files in Android:

<https://play.google.com/store/apps/details?id=com.cxinventor.file.explorer>

About viewing locally stored HTML files: usually some things are not
possible due to security restrictions, since the references in the file
need to be translated to Storage Access Framework requests which is not
that simple.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Maria Sophia, 2026-07-05 04:51:

Maria Sophia wrote:

Apparently, Android only allows browsers to read:
/storage/emulated/0/Download/
/storage/emulated/0/Documents/
/storage/emulated/0/DCIM/
/storage/emulated/0/Pictures/

This is frustrating as Android seems to be getting more & more like iOS
as it appears that Android's WebView (used by all browsers) cannot open:
file:///storage/emulated/0/0000/...

This was never possible. Apps can NEVER access the filesystem outside
their own sandbox. Also before Android 5 this was a special API call
only possible, if the app has the permission for it. And nowadays, the
SAF is the preferred way to access files for security reasons.

So I need to find an app that still use direct POSIX filesystem access (and ignores SAF entirely), or, I can install a local HTTP server in Termux.

You can't find such an app, since this is not possible.

3. In Termux, install python.
$ pkg install python

4. In Termux, start the server
$ python3 -m http.server 8000
Serving HTTP on :: pot 8000 (http://[::]:8000) ...

5. Open any browser and type the following into the url address field
http://localhost:8000

6. Using the Privacy Browser, that brought up the top-level web page.
Then, I tapped on the first link... ... ... Voila!
The manual page2 showed up perfectly this time.

Whew!
Success at last!

Yes, because python3 is *not* an "app", it is just a program.

apps are *not* programs which just start and do something. They are
packages providing handlers for "actions" like "intentions" and in some
cases also provide services like "handle incoming TCP connection" or "do something once an hour" etc.. - but you must not confuse "app" with
"program".

And no, this was never different in Android - even the very first
Android versions worked like this.
--
Arno Welzel
https://arnowelzel.de
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote:

Q: I have recently seen "books" transferred as a ZIP archive of a large
html tree. Calibre calls a browser to see a page at a time, AFAIK. I
wonder if there is software that displays that ZIP as a book directly, better on a tablet.

Yes. What you've seen is often called an **HTMLZ** (HTML in a ZIP), or simply a ZIP containing a static website. It's a nice format because it preserves hyperlinks, CSS, images, and search indexes while compressing
very well.

The difficulty is that there isn't a universally adopted "book reader"
for zipped HTML trees analogous to EPUB readers.

Here are the main options:

* **Calibre**: as you note, it essentially extracts or serves the HTML
and uses an embedded browser. It isn't really a dedicated HTML book renderer.

* **KOReader** (Android, Linux, Kobo, Kindle): probably the closest to
what you're looking for. It primarily supports EPUB, PDF, DjVu, etc.,
but it can also browse HTML files. However, it doesn't natively treat an arbitrary ZIPped website as a single book.

* **Static website in a browser**: on Android or Linux you can simply
unzip the archive and open `index.html`. Browsers do a surprisingly good job. Firefox on Android, for example, can open local HTML files (with a
bit of help from a file manager).

* **Mini HTTP server**: many people run

```bash
python3 -m http.server
```

in the extracted directory and browse to `http://localhost:8000/`.
This avoids issues some browsers have with `file://` URLs and JavaScript.

### Why EPUB became dominant

An EPUB is essentially:

```
book.epub
„€€ ZIP archive
†€€ XHTML files
†€€ CSS
†€€ images
†€€ metadata
„€€ navigation (table of contents)
```

So EPUB is really a standardized HTML tree in a ZIP with metadata.
Readers know how to paginate it, remember your position, annotate,
search, adjust fonts, etc. A raw ZIP of HTML lacks that standard structure.

### If your documentation is generated

For things like Rust docs, Python docs, man-page collections, or API documentation, I would actually **keep them as HTML** rather than
converting to EPUB. Documentation relies on hyperlinks more than on
linear reading, and browsers excel at that.

### An interesting possibility

It wouldn't be hard to write a small application that:

* opens a ZIP without extracting it permanently,
* serves its contents through an embedded HTTP server,
* displays them in a WebView,
* remembers your position and reading history.

Modern ZIP libraries allow random access, so the pages needn't even be unpacked to disk. I'm a little surprised there isn't a well-known open-source app that does exactly this, because it would be ideal for offline documentation on a tablet.

Out of curiosity, are you mainly thinking of **technical documentation** (Rust, Python, Linux man pages, etc.), or of **books** distributed as
HTML? The best tool tends to differ between those two use cases.

Q: I was thinking of that rust documentation, but as an example of the system.

I think the Rust documentation is actually an excellent example because
it's *not* a linear book in the EPUB sense. It's a small self-contained website. That changes what the ideal reader looks like.

If I were designing an offline documentation system today, I'd package
it as:

```
rust-book.zip
†€€ index.html
†€€ ch01.html
†€€ css/
†€€ fonts/
†€€ images/
†€€ search-index.js
„€€ ...
```

and the "reader" would simply:

* mount or read the ZIP directly;
* expose it through an internal HTTP server (or a custom URL scheme);
* render it in a browser component (WebView, Qt WebEngine, etc.);
* remember the last page, bookmarks, and maybe annotations.

No conversion to EPUB would be necessary.

The nice thing is that all the navigation, CSS, search, and JavaScript already exist. You'd just be providing a pleasant container around them.

### Existing software gets close

There are a few projects in the same spirit:

* **Zeal** (Linux/Windows) and **Dash** (macOS) store documentation in compressed docsets. Internally, these are HTML trees plus an index
database. They're aimed at API documentation rather than books.
* **DevDocs Offline** projects cache the HTML documentation for offline use. * Browser-based **Progressive Web Apps** can cache entire documentation sites for offline use, although support varies.

The common theme is that they're all essentially shipping HTML, not inventing a new document format.

### Why browsers aren't terrible readers anymore

Twenty years ago, HTML was a poor "book" format because pages were
static and browsers had little support for reading workflows. Nowadays browsers have:

* full-text search,
* history,
* zoom,
* dark mode,
* responsive layout,
* good typography,
* JavaScript-based navigation.

For technical documentation, that's often *better* than an EPUB reader, because the documentation was authored as a website in the first place.

### A feature I'd still like to see

One thing I haven't seen is a generic **"ZIP book reader"**: point it at
any ZIP containing an `index.html`, and it treats it like a book. It
would need only a handful of features:

* open ZIP without extracting it;
* detect the entry page (`index.html`);
* keep reading position;
* bookmarks;
* optional full-text search (using an embedded index if present).

That would cover not only the Rust Book, but also many documentation bundles, offline manuals, and even archived wikis. It's a surprisingly simple concept, yet I don't know of a mainstream application dedicated
to it.

Wow. That was jam-packed with good information. Let's summarize first.

HTMLZ = HTML-in-a-ZIP.
It's literally just a ZIP file containing a folder of HTML pages, images,
CSS and JavaScript. It's apparently what my reference manual happens to be.

EPUB is basically the same idea, but with a standardized structure and
extra metadata so book readers know how to paginate, bookmark, search, etc.

Apparently there is no universal HTMLZ reader on tablets.
EPUB readers exist everywhere, but HTMLZ readers do not.

Generally we can read a ZIPped HTML tree by
a. Unzipping it and opening index.html in a browser
(which is what I did on Windows and it would work on Linux too)
b. Or running a tiny local web server and browsing to it
(which Andy, Carlos & I had to do on Android due to SAF rules)
c. Or using specialized documentation apps (Zeal, Dash, DevDocs)
(none of which do I have any experience whatsoever using)
i. Zeal (Linux/Windows)
ii. Dash (macOS/iOS)
iii. DevDocs (offline, for programming docs)
iv. Kiwix (reads ZIM files, not ZIPs, but can convert)

I agree that, for technical documentation, HTML is often better than EPUB because it's designed for hyperlinks, search and non-linear navigation.

It would be nice if someone writes a simple app that opens a ZIP, serves it internally and displays it like a book-because it would solve all of this .

In my Android 16 case, and also in the case of Andy & Carlos on Android,
the real problem was SAF doesn't allow relative URLs in custom folders.

So any solution that works on Android, has to take SAF limitations into account, where I looked up how to view these thigns on iOS & it's similar.

On Android, we found that running a tiny web server worked.
But on Android 10+, we could also have tried what Carlos used:
a. An older version of CX file Manager has a built-in web server
b. So does X-plore File Manager
c. And I'm told MiXplorer has excellent HTML-Z handling features

Interestingly, iOS seems to handle relative links *better* than Android.
What's *different* about iOS is that iOS doesn't use SAF. Yipee!

An HTMLZ (a ZIP full of HTML with relative paths) will work on an iPad.
a. iPadOS does not break relative links the way Android 10+ does.
b. iPadOS does support relative paths inside an HTMLZ
c. iPadOS gives the browser real filesystem paths, not SAF streams.
d. So the browser sees the directory structure normally.
This means the 500MB shop manual will behave like a normal offline website. Safari will load the entire manual correctly.

Even so, we can still use the server method on iOS as we did on Android.
All of thse can run the same "python3 -m http.server" we used on Android.
a. iSH (Linux emulator)
b. Pythonista
c. Kodex
Once we start the HTTP server in $DOCUMENT_ROOT, then we point a browser to
<http://localhost:8000/>

So, had I tried my iPads first, prior to Android, it would have worked. (Although it's an Apple disaster trying to get a large file onto the iPad.)

In summary, on Android 10+ the SAF mechanism destroys POSIX paths outside
of the four public directories for web browser, so in order to put huge
complex HTML-Z documentation on Android 16 outside of the four public directories, we had to employ a local server (or convert to EPUB/PDF).

Overall, I'm glad I ran into this problem because I learned about SAF and
how it screws up POSIX file paths in custom folders when browsing HTML.

And, I learned from testing Calibre for Carlos that EPUBs have a fantastic search mechanism for extremely complex data structures (as good as PDF).

And I learned that for huge, image-heavy, cross-linked manuals, HTML in a browser is the fastest method, so there's a place for HTMLZ after all.
--
I don't favor platforms; I measure them as I report truthfully about them.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Arno Welzel wrote:

Maria Sophia, 2026-07-05 04:51:

Maria Sophia wrote:

Apparently, Android only allows browsers to read:
/storage/emulated/0/Download/
/storage/emulated/0/Documents/
/storage/emulated/0/DCIM/
/storage/emulated/0/Pictures/

This is frustrating as Android seems to be getting more & more like iOS
as it appears that Android's WebView (used by all browsers) cannot open:
file:///storage/emulated/0/0000/...

This was never possible. Apps can NEVER access the filesystem outside
their own sandbox. Also before Android 5 this was a special API call
only possible, if the app has the permission for it. And nowadays, the
SAF is the preferred way to access files for security reasons.

So I need to find an app that still use direct POSIX filesystem access (and >> ignores SAF entirely), or, I can install a local HTTP server in Termux.

You can't find such an app, since this is not possible.

3. In Termux, install python.
$ pkg install python

4. In Termux, start the server
$ python3 -m http.server 8000
Serving HTTP on :: pot 8000 (http://[::]:8000) ...

5. Open any browser and type the following into the url address field
http://localhost:8000

6. Using the Privacy Browser, that brought up the top-level web page.
Then, I tapped on the first link... ... ... Voila!
The manual page2 showed up perfectly this time.

Whew!
Success at last!

Yes, because python3 is *not* an "app", it is just a program.

apps are *not* programs which just start and do something. They are
packages providing handlers for "actions" like "intentions" and in some
cases also provide services like "handle incoming TCP connection" or "do something once an hour" etc.. - but you must not confuse "app" with "program".

And no, this was never different in Android - even the very first
Android versions worked like this.

Hi Arno,

Thanks for weighing in as I had never even thought about this problem
before, and, in fact, while I knew about SAF, I didn't understand it.

As we found out later in the thread, the problem isn't Android sandboxing.
It's WebView rewriting file:// paths inside of custom folders into SAF content:// URIs, which breaks relative links. Termux works because it
bypasses WebView. So it's not an access problem. It's a POSIX problem.

Looking up all your information, you're correct that apps cannot freely (without permission) access arbitrary paths like /storage/emulated/0/0000 (which are outside the public folders) which has always been the case.

And you're correct SAF is now the preferred method for user-selected files.
And you are right that Termux + python3 works because it's not a WebView.
a. Termux runs native binaries, not WebView
b. The local HTTP server bypasses SAF entirely

But prior to Android 10, browsers could open local directories using file:///storage/emulated/0/... paths directly if they had permission.

But Android 10+ changed this behavior but Apps can still access shared
storage if they have the permission to do so, such as
a. READ_EXTERNAL_STORAGE
b. WRITE_EXTERNAL_STORAGE
c. or user-granted SAF access

This is why file managers, browsers, media players, and editors can read /storage/emulated/0/....

What changed is how they access it.

As for finding an app that ignores SAF, clearly Termux ignores SAF.
Termux has direct POSIX access with no SAF and no WebView restrictions.

Other apps also bypass SAF:
a. MiXplorer
c. X-plore
d. Cx File Explorer
e. VLC
f. Kodi
g. RetroArch
In fact, any app using native code instead of WebView bypasses SAF.

If you get a chance, read the rest of this thread, where it turns out that
the real problem was simply that SAF screws up relative links in my file.

It turned out, much later, that it's not that apps can't access the
filesystem, but that Android WebView rewrites file paths that are in custom folders into SAF content URIs, which was breaking the HTMLZ relative links.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-06 18:28, Maria Sophia wrote:

Carlos E. R. wrote:

Q: I have recently seen "books" transferred as a ZIP archive of a large
html tree. Calibre calls a browser to see a page at a time, AFAIK. I
wonder if there is software that displays that ZIP as a book directly,
better on a tablet.

...

I agree that, for technical documentation, HTML is often better than EPUB because it's designed for hyperlinks, search and non-linear navigation.

It would be nice if someone writes a simple app that opens a ZIP, serves it internally and displays it like a book-because it would solve all of this .

In my Android 16 case, and also in the case of Andy & Carlos on Android,
the real problem was SAF doesn't allow relative URLs in custom folders.

So any solution that works on Android, has to take SAF limitations into account, where I looked up how to view these thigns on iOS & it's similar.

On Android, we found that running a tiny web server worked.
But on Android 10+, we could also have tried what Carlos used:
a. An older version of CX file Manager has a built-in web server

It is a current tablet with Android 16 and a current version of CX,
installed via Google Play, version 2.7.6. I tried an html tree, not htmlz.

b. So does X-plore File Manager
c. And I'm told MiXplorer has excellent HTML-Z handling features

Interestingly, iOS seems to handle relative links *better* than Android. What's *different* about iOS is that iOS doesn't use SAF. Yipee!

An HTMLZ (a ZIP full of HTML with relative paths) will work on an iPad.
a. iPadOS does not break relative links the way Android 10+ does.
b. iPadOS does support relative paths inside an HTMLZ
c. iPadOS gives the browser real filesystem paths, not SAF streams.
d. So the browser sees the directory structure normally.
This means the 500MB shop manual will behave like a normal offline website. Safari will load the entire manual correctly.

Even so, we can still use the server method on iOS as we did on Android.
All of thse can run the same "python3 -m http.server" we used on Android.
a. iSH (Linux emulator)
b. Pythonista
c. Kodex
Once we start the HTTP server in $DOCUMENT_ROOT, then we point a browser to
<http://localhost:8000/>

So, had I tried my iPads first, prior to Android, it would have worked. (Although it's an Apple disaster trying to get a large file onto the iPad.)

In summary, on Android 10+ the SAF mechanism destroys POSIX paths outside
of the four public directories for web browser, so in order to put huge complex HTML-Z documentation on Android 16 outside of the four public directories, we had to employ a local server (or convert to EPUB/PDF).

Overall, I'm glad I ran into this problem because I learned about SAF and
how it screws up POSIX file paths in custom folders when browsing HTML.

And, I learned from testing Calibre for Carlos that EPUBs have a fantastic search mechanism for extremely complex data structures (as good as PDF).

And I learned that for huge, image-heavy, cross-linked manuals, HTML in a browser is the fastest method, so there's a place for HTMLZ after all.

--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-06 17:36, Maria Sophia wrote:

Carlos E. R. wrote:

I fed my 500MB zip file into Calibre and told it to convert it to an EPUB, >>> which took a few hours on my 2009 Windows 10 PC, but it worked beautifully. >>

Wow. My laptop took a few seconds, but it was just a 2.5 MiB zip.

My desktop is from 2009. It's still working well, but this stressed it. :)

The resulting EPUB file was 400MB so it took a while for Calibre to load it >>> the first time (due to all the caching that Calibre does on first loading). >>

I have never seen an epub that big. In my case, the book that I tested
with can be purchased in epub format. Possibly the epub is available on
the emule network or such (for testing, of course).

My experience had been the same as yours. EPUBs are generally quite small. This one has tens of thousands of separate images yet very little text.

When I looked at the file inside of Thorium, I got an appreciation for why >>> HTML is an excellent medium, as there were tens of thousands of connected >>> pages and images, where an EPUB can handle it, but it's slow as all hell. >>>
Since the EPUB itself was 400MB, I didn't even bother copying to Android. >>> If it's slow on Windows, it's likely gonna be even slower on Android.

The HTML is, by way of contrast, is virtually instant when clicking about. >>>
When I tried to convert the EPUB to a PDF, Calibre failed (with what seemed >>> like memory errors) after about an hour or two, so I gave up on the PDF.

I don't like PDF for books, because it doesn't flow the text. It is
fixed size. You need a display that matches the design size and
resolution (or better).

I agree that PDF isn't all that great for books in that, for me, my eyes aren't so great and a PDF makes you sit and stare at it to read it.

Maybe it would be easier to read in an ebook device, using epaper which doesn't shine.

I prefer to convert the (text) PDF to audio using cross platform balabolka freeware which then turns any (text) PDF into an audio book.

It's not as good as a human reader for some books, e.g., when I converted Einstein's 1916 (updated in 1922) book on relativity, calculations are
messed up when spoken by balabolka's conversion utilities.

But now I'm one of the few non-physicists who understand gravity as a
result, since I was in a compression/decompression chamber for a month.

As an aside, almost nobody understands gravity. One in a million I'd bet.
And even as I understand it to that level, there's still much I don't know.

Looking into my c:\app\editor\epub directory, these seem to be most common >>> cross platform EPUB readers, where I've sorted by large file handling.
thorium
most stable & fastest for huge image-heavy epubs like textbooks
calibre
most powerful for conversion & repair of image-heavy epubs
redium desktop
sibling of thorium but less polished than thorium
okular
KDE document viewer with medium-level EPUB support via plugins
hamster
best for small epubs
lucidor
best for very small epubs
fbreader
suitable for smaller epubs
adobe digital editions
not suitable as the epub engine is old and fragile
sumatra pdf
fast for small epubs

In summary, for certain kinds of references (such as highly cross-linked >>> highly imaged technical manuals and textbooks), a zip HTML is likely ideal. >>

Seeing that calibre imports the html directory as a zip file, it is
possible that there is software out there that directly renders readable
those ZIP files. Or even hardware.

I agree that Calibre had no problem importing the single 500MB zip file.
It just took a long time, but Calibre didn't even blink on the contents.

It's just that my circa 2009 PC runs slowly when it's time to crunch it.

I've learned there's a good reason highly cross-linked documents filled
with images and almost no text are supplied in a zip file HTML format.

It's amazing how fast HTML is compared to the EPUB, although the epub has
the distinct advantage of a fantastic search mechanism that shocked me.

With EPUB, when you search, you get every instance but every line of every instance (much like you'd get with a (text) PDF, so that was really nice.

Yes, my kobo reader does search easily, I noticed.

So if you need to search a huge 500MB HTML document containing tens of thousands of files, converting it to a 400MB EPUB allows that fantastic search, but if you need to actually navigate it, an HTML server wins out.

--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-05 10:37, Computer Nerd Kev wrote:

In comp.mobile.android,alt.os.linux,alt.comp.os.windows-10 "Carlos E. R." <robin_listas@es.invalid> wrote:

On 2026-07-05 15:48, Dave Royal wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again.
I carved out a sane workflow inside an OS that keeps trying to turn into >>>>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!) >>>>>
Windows and Linux can easily open HTML books stored in custom top-level >>>>> hierarchies, even if the books contain tens of thousands of pages & jpegs.

Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
top-level POSIX folders such as /storage/emulated/0/0000/books/book1/. >>>>

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them >>>> with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as >>>> an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation

Ok...

Heh, they charge 45$ for the epub version.

No ZIP that I can see :-?

I would have to download using wget, and this tool modifies the links so
that they are correct for your local installation.

I wonder if Calibre can convert that to epub.

As I posted about in (rec.autos.tech) last month:
Subject: Free Vehicle Service Manuals
Date: 11 Jun 2026
Message-ID: <6a2a43e6@news.ausics.net>

I've been using Operation CHARM for some time (https://charm.li/),
which covers vehicles (USA & Canada models) from 1982 to 2013. Now I
see there's a new site, LEMON, with service manuals for vehicles
from 1960 to 2025:

https://lemon-manuals.la/

Now THAT is a useful resource!
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-05, Maria Sophia wrote:

Luckily, Termux can access the real filesystem directly using standard Unix system calls, without Android rewriting the paths into SAF content:// URIs. Because Termux sees the actual directory structure, it can serve the HTML manual correctly, and all relative links work.

Can Termux list the internal and external storage directories under
/storage?

With Emacs, I can access these directories if I know their name, but it
is still not exposed as a walkable hierarchy, because Emacs sees
/storage as empty.

I tried creating a symlink so that programs could still access both
directories from a single root somehow, but that's apparently not
allowed either. I can (and I did) create symlinks within Emacs' home
dir, but that's local to Emacs (or possibly Emacs and Termux in builds
made for that integration - I didn't try such a thing yet), it's not
something other applications could use after being done once.

This also creates a usability problem in other programs, like file
explorers or KOReader, or at least KOReader and Fossify File Manager
cannot offer it as a walkable tree with a single root, and instead
require me to go through a choice menu for internal or external
storage. (Although the file manager could always create a fake root in
the interface instead of making that part of the interaction different.)

KOReader on Android 4.2 is capable of moving between both storages just
by changing between folders in the VFS, making this effectively a
downgrade...
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-05, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again. >> I carved out a sane workflow inside an OS that keeps trying to turn into
iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!)

Windows and Linux can easily open HTML books stored in custom top-level hierarchies, even if the books contain tens of thousands of pages & jpegs.

Unfortunately, Android 10 through 16 cannot open HTML book stored in custom top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

All Android web browsers use WebView, which is restricted by Scoped Storage and the Storage Access Framework (SAF). When you try to open index.html, Android does not give the browser the real filesystem path.

Instead it rewrites the path into a SAF URI like:
content://com.android.externalstorage.documents/document/primary%3A0000%2Fbooks%2Fbook1%2Findex.html

SAF URIs are not real filesystem paths.
Because of this, all relative links inside the book1 break.

For example:
pages/2.html
images/foo.png
css/style.css

These links get rewritten into invalid SAF document URIs such as:
content://com.android.externalstorage.documents/document/pages/2.html

Browsers cannot resolve these, so they fail with errors like
ERR_ACCESS_DENIED and ERR_FILE_NOT_FOUND.

Android WebView only allows file:// access in a few public folders (Download, Documents, DCIM, Pictures) but Linux users often use custom folders like /usr/local so that they can back up everything they care about easily, and so that they're not polluted by the Android system.

Custom folders like /0000 are blocked.

Unzipping the book1 works fine, but opening index.html directly from
the top-level /0000 fails in every browser tested.

Solution:
Use Termux to bypass SAF entirely. Termux uses real POSIX filesystem
access. After granting Termux full file permissions in Android Settings,
you can run a local HTTP server that serves the book1 using real paths.

Steps:
1. Install Termux from GitHub or F-Droid.
2. Grant Termux "All files access" in Android Settings.
3. In Termux, install Python:
pkg install python
4. Navigate to the book1 directory:
cd /storage/emulated/0/0000/books/book1
5. Start a local HTTP server:
python3 -m http.server 8000
6. Open any browser and go to:
http://localhost:8000

Because the book1 is now served over HTTP, the browser treats it as a
normal website. All relative links, images, CSS, and subpages work
correctly. This bypasses SAF and restores normal filesystem behavior.

Result:
The entire HTML book named book1 displays perfectly on Android while remaining in the user's own custom directory (/0000) so that it can
be copied over during backups along with the rest of the users' data.

AFAIK, this method works reliably on all modern Android versions.

BTW, I didn't try with anything complex, but a quick test with two HTML
files, a link between them, and one of them using an inline image worked
for file:///storage/[dirname]/path/to/html in Emacs' eww, under Android
15. As in, both documents loaded, the same-directory inline image
loaded, and the same-directory relative link worked too.

Might not be useful at all, or may only be useful for simpler content of
some sort, but given that I tested, I thought I'd add this datapoint.

Might be useful for myself in the future, too.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-05, Carlos E. R. wrote:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again. >>> I carved out a sane workflow inside an OS that keeps trying to turn into >>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy. >>

SUMMARY (Linux users added because it was Linux to the rescue this time!)

Windows and Linux can easily open HTML books stored in custom top-level
hierarchies, even if the books contain tens of thousands of pages & jpegs. >>
Unfortunately, Android 10 through 16 cannot open HTML book stored in custom >> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them
with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless
as an intermediary to transform to something else.

(Wasn't epub a Zip archive of a HTML book?)

(Ok, Wikipedia says XHTML?)
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-06, Arno Welzel wrote:

Maria Sophia, 2026-07-05 04:51:

Maria Sophia wrote:

Apparently, Android only allows browsers to read:
/storage/emulated/0/Download/
/storage/emulated/0/Documents/
/storage/emulated/0/DCIM/
/storage/emulated/0/Pictures/

This is frustrating as Android seems to be getting more & more like iOS
as it appears that Android's WebView (used by all browsers) cannot open:
file:///storage/emulated/0/0000/...

This was never possible. Apps can NEVER access the filesystem outside
their own sandbox.

This does not imply that. It was possible because the sandboxing did not prevent that access, or at least didn't have barriers as big as Android
has now.

In older Android versions, at least non-rooted, applications still
cannot access the whole filesystem (e.g. data from other applications),
but *can* access internal and external storage as exposed under /storage/.

Also before Android 5 this was a special API call
only possible, if the app has the permission for it. And nowadays, the
SAF is the preferred way to access files for security reasons.

I'd say it breaks too many things to be useful overall. But where it
works, well, then maybe it's useful there.

So I need to find an app that still use direct POSIX filesystem access (and >> ignores SAF entirely), or, I can install a local HTTP server in Termux.

You can't find such an app, since this is not possible.

[ /me glances at Emacs on Android doing exactly that ]

3. In Termux, install python.
$ pkg install python

4. In Termux, start the server
$ python3 -m http.server 8000
Serving HTTP on :: pot 8000 (http://[::]:8000) ...

5. Open any browser and type the following into the url address field
http://localhost:8000

6. Using the Privacy Browser, that brought up the top-level web page.
Then, I tapped on the first link... ... ... Voila!
The manual page2 showed up perfectly this time.

Whew!
Success at last!

Yes, because python3 is *not* an "app", it is just a program.

apps are *not* programs which just start and do something. They are
packages providing handlers for "actions" like "intentions" and in some
cases also provide services like "handle incoming TCP connection" or "do something once an hour" etc.. - but you must not confuse "app" with "program".

That may be true, but is that distinction relevant here? Does this play
any role in the access permissions?

And no, this was never different in Android - even the very first
Android versions worked like this.

Then Samsung must have heavily modified the older Android system I've
used, because there are several differences making access more
difficult in Android 15.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Nuno Silva wrote:

On 2026-07-05, Maria Sophia wrote:

Luckily, Termux can access the real filesystem directly using standard Unix >> system calls, without Android rewriting the paths into SAF content:// URIs. >> Because Termux sees the actual directory structure, it can serve the HTML
manual correctly, and all relative links work.

Can Termux list the internal and external storage directories under
/storage?

With Emacs, I can access these directories if I know their name, but it
is still not exposed as a walkable hierarchy, because Emacs sees
/storage as empty.

I tried creating a symlink so that programs could still access both directories from a single root somehow, but that's apparently not
allowed either. I can (and I did) create symlinks within Emacs' home
dir, but that's local to Emacs (or possibly Emacs and Termux in builds
made for that integration - I didn't try such a thing yet), it's not something other applications could use after being done once.

This also creates a usability problem in other programs, like file
explorers or KOReader, or at least KOReader and Fossify File Manager
cannot offer it as a walkable tree with a single root, and instead
require me to go through a choice menu for internal or external
storage. (Although the file manager could always create a fake root in
the interface instead of making that part of the interaction different.)

KOReader on Android 4.2 is capable of moving between both storages just
by changing between folders in the VFS, making this effectively a downgrade...

I haven't tested Termux but I am testing adb in the same way as above.

I'm learning the hard way that Android has an amazingly complex system for
the filespec that any given app can use to read, write or even delete
files, as can be seen by this adb copy program I'm working on as we speak.

To the point of multiple paths to the same file, before I dealt with the fashuganah "media store" file naming conventions, I was getting the same deleted files returning time and time again, until I realized that
mediastore will force the files back even if you delete them and worse, mediastore uses a different file name (no spaces) for your deleted file.

Sigh.

Note this is an unfinished script, so just note the complexities involved.
In this script, I am mostly using it for the step 1 and then step 4 copies.

Note that it started out as copying only "today's" dated image files.
then it morphed to copying all image files over adb on Wi-Fi (or USB).

:: adbcopy.bat
:: v3p0 20260708 added dual-layer deletion (filesystem + mediastore)
:: which prevents FUSE from repeatedly restoring ghost files
:: and which handles private-app sandbox directories
:: v2p9 20260707 fixed quoting and path issues caused by filenames with spaces
:: v2p8 20260707 skip empty directories before prompting user
:: v2p7 20260702 delete only files (not folders)
:: v2p6 20260701 auto-detect all DCIM subdirectories
:: v2p5 20260701 expanded image file matching
:: v2p4 20260701 added internal DCIM/Camera option
:: v2p3 20260621 open destination folder when done
:: v2p2 20260617 added screenshot directory detection
:: v2p2 20260612 fixed quoting bug in DCIM ls command
:: v2p1 20260607 added Windows-to-Android APK install mode
:: v2p0 20260603 added Screenshot directory support
:: v1p9 20260528 trim trailing spaces from destination path
:: v1p8 20260528 replaced destructive path truncation with CR stripping
:: v1p7 20260528 escaped redirection character in backtick loop
:: v1p6 20260528 updated external SD card path handling
:: v1p5 20260528 fixed null-redirection error and stabilized extraction
:: v1p4 20260528 fixed "unexpected at this time" crash
:: v1p3 20260528 fixed crash on empty variable comparison
:: v1p2 20260528 fixed multi-device detection and nested quoting
:: v1p1 20260528 added debug output for failure cases
:: v1p0 20260528 initial version: copy images by date

@echo off
setlocal enabledelayedexpansion

cd /d "%~dp0"
set "ADB_EXE=c:\app\editor\android\scrcpy\adb.exe"

:: --- DEVICE DETECTION ---
for /f "skip=1 tokens=1" %%g in ('"%ADB_EXE%" devices') do (
if not "%%g"=="" (
if "!ADB_TARGET!"=="" set "ADB_TARGET=%%g"
)
)

if "!ADB_TARGET!"=="" (
echo [ERROR] No connected ADB devices found.
pause
exit /b
)

echo Targeting device: %ADB_TARGET%
echo ----------------

:: --- MAIN DIRECTION MENU --- default is [1] ---
echo Select Direction:
echo [1] Android to Windows (Pull Images/Screenshots) [Default]
echo [2] Windows to Android (Copy/Install APK)
echo.
set "CHOICE=1"
set /p "CHOICE=Enter choice [1 or 2]: "

if "%CHOICE%"=="2" goto :windows_to_android
if "%CHOICE%"=="1" goto :android_to_windows
goto :android_to_windows


:: ROUTINE: ANDROID TO WINDOWS
:android_to_windows
echo.
echo --- Running Android to Windows Pull ---

echo.
echo What do you want to pull?
echo [1] Camera photos (SD Card DCIM/Camera)
echo [2] Screenshots
echo [3] Camera photos (Internal Storage DCIM/Camera)
echo [4] Pull directories one-by-one (user selected)
set "PULL_CHOICE=1"
set /p "PULL_CHOICE=Enter choice [1, 2, 3 or 4]: "

:: Only ask for date if pulling dated files
if "%PULL_CHOICE%"=="4" goto :skip_date

:: --- DATE DETECTION ---
for /f "tokens=2 delims==" %%i in ('wmic os get localdatetime /value') do set "dt=%%i"
set "DETECTED_DATE=%dt:~0,8%"

echo Detected Date: %DETECTED_DATE%
set /p "USER_DATE=Press Enter to confirm, or type a different date (YYYYMMDD): "
if "%USER_DATE%"=="" (
set "TARGET_DATE=%DETECTED_DATE%"
) else (
set "TARGET_DATE=%USER_DATE%"
)

:skip_date

echo.
if "%PULL_CHOICE%"=="4" (
rem Interactive, pulling everything ¡V no date-based subfolder
set "DEST_DIR=H:\003_camera\20260701"

) else (
rem Date-based pulls still go into YYYYMMDD subfolder
set "DEST_DIR=H:\004_upload\home\pool\assay\%TARGET_DATE%"
)

set /p "USER_DIR=Enter destination directory [Default: %DEST_DIR%]: "
if not "%USER_DIR%"=="" set "DEST_DIR=%USER_DIR%"

:: Remove quotes
set "DEST_DIR=%DEST_DIR:"=%"

:: Trim trailing spaces
:trim
if "!DEST_DIR:~-1!"==" " (
set "DEST_DIR=!DEST_DIR:~0,-1!"
goto trim
)

if not exist "%DEST_DIR%" (
echo Creating directory: %DEST_DIR%
mkdir "%DEST_DIR%"
)

if "%PULL_CHOICE%"=="1" goto :pull_camera
if "%PULL_CHOICE%"=="2" goto :pull_screenshots
if "%PULL_CHOICE%"=="3" goto :pull_camera_internal
if "%PULL_CHOICE%"=="4" goto :pull_interactive_dirs

goto :pull_camera



if "%PULL_CHOICE%"=="1" goto :pull_camera
if "%PULL_CHOICE%"=="2" goto :pull_screenshots
if "%PULL_CHOICE%"=="3" goto :pull_camera_internal
if "%PULL_CHOICE%"=="4" goto :pull_interactive_dirs

goto :pull_camera

:: PULL CAMERA (DCIM)
:pull_camera
echo.
echo Pulling CAMERA images matching *%TARGET_DATE%*.jpg ...
echo Sending files to: "%DEST_DIR%"
echo ----------------

for /f "usebackq delims=" %%i in (`
%ADB_EXE% -s !ADB_TARGET! shell ls /storage/0CA4-352D/DCIM/Camera/*%TARGET_DATE%*.jpg
`) do (
set "FILE_PATH=%%i"
for /f "delims=" %%r in ("!FILE_PATH!") do set "FILE_PATH=%%r"
if not "!FILE_PATH!"=="" (
echo Pulling: !FILE_PATH!
"%ADB_EXE%" -s !ADB_TARGET! pull "!FILE_PATH!" "%DEST_DIR%"
)
)

goto :complete


:: PULL SCREENSHOTS
:: PULL SCREENSHOTS (handle both directories explicitly)
:pull_screenshots
echo.
echo Pulling SCREENSHOTS matching *%TARGET_DATE%*.jpg ...
echo Sending files to: "%DEST_DIR%"
echo ----------------

:: Directory A ¡X Android 11 legacy
for /f "usebackq delims=" %%i in (`
%ADB_EXE% -s !ADB_TARGET! shell ls /sdcard/DCIM/Screenshots/*%TARGET_DATE%*.jpg
`) do (
set "FILE_PATH=%%i"
if not "!FILE_PATH!"=="" (
echo Pulling (legacy): !FILE_PATH!
"%ADB_EXE%" -s !ADB_TARGET! pull "!FILE_PATH!" "%DEST_DIR%"
)
)

:: Directory B ¡X Android 13 modern
for /f "usebackq delims=" %%i in (`
%ADB_EXE% -s !ADB_TARGET! shell ls /storage/emulated/0/DCIM/Screenshots/*%TARGET_DATE%*.jpg
`) do (
set "FILE_PATH=%%i"
if not "!FILE_PATH!"=="" (
echo Pulling (modern): !FILE_PATH!
"%ADB_EXE%" -s !ADB_TARGET! pull "!FILE_PATH!" "%DEST_DIR%"
)
)

goto :complete


:: PULL CAMERA (INTERNAL STORAGE DCIM)
:pull_camera_internal
echo.
echo Pulling CAMERA images from INTERNAL STORAGE matching *%TARGET_DATE%*.jpg ...
echo Sending files to: "%DEST_DIR%"
echo ----------------

for /f "usebackq delims=" %%i in (`
%ADB_EXE% -s !ADB_TARGET! shell ls /storage/emulated/0/DCIM/Camera/*%TARGET_DATE%*.jpg
`) do (
set "FILE_PATH=%%i"
for /f "delims=" %%r in ("!FILE_PATH!") do set "FILE_PATH=%%r"
if not "!FILE_PATH!"=="" (
echo Pulling: !FILE_PATH!
"%ADB_EXE%" -s !ADB_TARGET! pull "!FILE_PATH!" "%DEST_DIR%"
)
)
goto :complete




:: FINALIZE
:complete
start "" "%DEST_DIR%"
echo Process complete
pause
exit /b

:pull_interactive_dirs
echo.
echo --- Interactive Directory Pull Mode ---
echo Destination: "%DEST_DIR%"

echo.

:: --- Detect ALL folders under /storage/emulated/0/DCIM ---
echo Detecting DCIM folders...

rem Correct quoting: do NOT quote the ls command
"%ADB_EXE%" -s %ADB_TARGET% shell ls -d /storage/emulated/0/DCIM/*/ > "%TEMP%\dcimdirs.txt" 2>&1

echo.
echo --- Interactive Directory Pull Mode (adb uses the FUSE layer) ---
echo Destination: "%DEST_DIR%"
echo.

:: First pull all DCIM subfolders dynamically
for /f "usebackq delims=" %%D in ("%TEMP%\dcimdirs.txt") do (
echo Found DCIM folder: %%D
call :pull_dir "%%D"
)

:: Then pull the other known directories
call :pull_dir "/storage/emulated/0/Pictures"
call :pull_dir "/storage/emulated/0/Download"
call :pull_dir "/storage/emulated/0/Android/media/com.whatsapp/WhatsApp/Media/WhatsApp Images"
call :pull_dir "/storage/emulated/0/Android/media/net.psyberia.offlinemaps/OfflineMaps Exports"
call :pull_dir "/storage/emulated/0/ReadEra/Covers"
call :pull_dir "/storage/emulated/0/OziExplorer/System Data"
call :pull_dir "/storage/0CA4-352D/DCIM/Camera"
call :pull_dir "/sdcard/DCIM/Screenshots"

goto :eod

:pull_dir
set "DIR=%~1"

echo.
echo Directory: %DIR%

echo Listing files in %DIR% ...
%ADB_EXE% -s %ADB_TARGET% shell ls "%DIR%" > "%TEMP%\filelist_raw.txt"

:: Filter out directories ¡X keep only real files
> "%TEMP%\filelist.txt" (
for /f "usebackq delims=" %%Z in ("%TEMP%\filelist_raw.txt") do (
%ADB_EXE% -s %ADB_TARGET% shell "[ -f \"%DIR%/%%Z\" ]" && echo %%Z
)
)

:: Check if any real files exist
set "HASFILES="
for /f "usebackq delims=" %%Z in ("%TEMP%\filelist.txt") do set "HASFILES=1"

if not defined HASFILES (
echo No files found in %DIR%. Skipping.
goto :eod
)

:: Print the actual file list (Option A)
echo Files found:
type "%TEMP%\filelist.txt"
echo.

:: Ask user only if real files exist
set /p "ANS=Pull this directory? [y/N]: "
if /i not "%ANS%"=="y" goto :eod

echo Checking directory: %DIR%

:: Count files
set "COUNT=0"
for /f "usebackq delims=" %%C in ("%TEMP%\filelist.txt") do set /a COUNT+=1
echo Found %COUNT% files in %DIR%.

echo Pulling files...
for /f "usebackq delims=" %%F in ("%TEMP%\filelist.txt") do (
echo Pulling: %DIR%/%%F
%ADB_EXE% -s %ADB_TARGET% pull "%DIR%/%%F" "%DEST_DIR%"
)

:: delete the file and the MediaStore entry and handle space differences
:: Take into account many mediastore naming syntax and access intricacies
set /p "DEL=Delete original files from phone (and MediaStore)? [y/N]: "
if /i "%DEL%"=="y" (
echo Deleting originals and MediaStore entries...

for /f "usebackq delims=" %%F in ("%TEMP%\filelist.txt") do (

rem --- Delete file (handles spaces correctly) ---
echo Deleting file: %DIR%/%%F
"%ADB_EXE%" -s %ADB_TARGET% shell rm "\"%DIR%/%%F\""

rem --- Delete MediaStore entry using full filename (with spaces) ---
echo Deleting MediaStore entry for: %%F
"%ADB_EXE%" -s %ADB_TARGET% shell content delete --uri content://media/external/images/media --where "\"_data LIKE '%/%%F'\""
)
)

:eod
exit /b

REM end of adbcopy.bat
--
Every Usenet post should strive to show additional value that wasn't there.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. wrote:

I agree that PDF isn't all that great for books in that, for me, my eyes
aren't so great and a PDF makes you sit and stare at it to read it.

Maybe it would be easier to read in an ebook device, using epaper which doesn't shine.

What I found unintuitive was that it likely would have never had this
relative path problem had I used my iPads to put the shop manual on.

I didn't pick the iPads because I am aware that copying files from anything
NOT Apple to the iPad is miserable, but once copied over, relative paths
would have worked.

The way I would have copied it, had I not already invested in the Android solution, would be to use LocalSend on the desktop and on the iOS device.
Newsgroups: alt.comp.os.windows-10,alt.os.linux,comp.sys.mac.system
Subject: How to transfer & play videos from a PC to an iPad using LocalSend and VLC
Date: Sat, 27 Jun 2026 18:51:33 -0600
Message-ID: <111pr6k$37o9q$1@news.tcpreset.net>

Since Apple products are designed to NOT work in the real world (i.e., interoperability between platforms does not exist), I had to jump through
hoops to get movies from a desktop to a spot on iOS that VLC could get to.

In that case, I used LocalSend on the desktop and on the iOS device.
But interestingly, to get the movies from one iPad to another was a beast.

It turns out that apparently Apple breaks the LocalSend mDNS discovery mechanism, such that it turned out that AirDrop was what finally worked.

But even AirDrop has its issues because you have to realize Apple forces idiotic constraints between devices in that AirDrop apparently doesn't see
the files in VLC. So we moved them to Photos.

It gets even more arbitrarily stupid where, apparently, you get 10 minutes
on AirDrop. That's it. 10 minutes. Then it drops.

So you turn that 10-minute switch on over and over again.

Thirdly, for whatever strange reason, the owner of the second iPad has to
be in the first iPad's contacts.

WTF?
What are contacts even doing on an iPad?

Anyway, once we moved the movies into Photos and then after we added the
second owner's contact to the first iPad, then (and only then) AirDrop
worked. But not for long. It kept failing. And there's that 10 minutes.

While AirDrop eventually worked in the end, before trying AirDrop, we first tried iOS Wi-Fi file sharing using the iOS VLC Wi-Fi and we then tried the
iOS LocalSend on both iPads, but the two iPads would not discover each
other even though they both were on the same LAN.

It's not surprising that iOS VLC didn't work reliably on large files
because iOS throttles background network activity for sandboxed apps.

But having the iOS LocalSend not worksing was surprising since the original LocalSend copy worked perfectly between Windows and the iPad, but
apparently iOS blocks the discovery mechanism the iOS LocalSend uses.

LocalSend uses multicast DNS (mDNS), which, on the surface, is the same discovery protocol AirDrop uses, but without Apple's special privileges.

We got it done, as we always get what we need done, but just knowing that nothing Apple makes is designed to work in the real world is why we tried Android first when it came to viewing huge shop manuals on the tablet.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Dave Royal <dave@dave123royal.com> wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again. >>>> I carved out a sane workflow inside an OS that keeps trying to turn into >>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!) >>>
Windows and Linux can easily open HTML books stored in custom top-level
hierarchies, even if the books contain tens of thousands of pages & jpegs. >>>
Unfortunately, Android 10 through 16 cannot open HTML book stored in custom >>> top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them
with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as
an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation

It may be published as html, but nowadays most documentation is *written*
in Markdown or similar dialect. With Markdown it's very easy to export into different formats like html, docx or pdf. There's no need save the book in html.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. <robin_listas@es.invalid> wrote:

On 2026-07-05 15:48, Dave Royal wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again. >>>>> I carved out a sane workflow inside an OS that keeps trying to turn into >>>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!) >>>>
Windows and Linux can easily open HTML books stored in custom top-level >>>> hierarchies, even if the books contain tens of thousands of pages & jpegs. >>>>
Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them
with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as >>> an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation

Ok...

Heh, they charge 45$ for the epub version.

No ZIP that I can see :-?

I would have to download using wget, and this tool modifies the links so that they are correct for your local installation.

I wonder if Calibre can convert that to epub.

No need. If you go to the github you can download the source and build it
in whatever format you want.

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

On 2026-07-08 19:51, Chris wrote:

Carlos E. R. <robin_listas@es.invalid> wrote:

On 2026-07-05 15:48, Dave Royal wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again.
I carved out a sane workflow inside an OS that keeps trying to turn into >>>>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!) >>>>>
Windows and Linux can easily open HTML books stored in custom top-level >>>>> hierarchies, even if the books contain tens of thousands of pages & jpegs.

Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
top-level POSIX folders such as /storage/emulated/0/0000/books/book1/. >>>>

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them >>>> with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as >>>> an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation

Ok...

Heh, they charge 45$ for the epub version.

No ZIP that I can see :-?

I would have to download using wget, and this tool modifies the links so
that they are correct for your local installation.

I wonder if Calibre can convert that to epub.

No need. If you go to the github you can download the source and build it
in whatever format you want.

Ah. Right. Did not occur to me, but in the past I had little luck with
doc building.
--
Cheers,
Carlos E.R.
ES🇪🇸, EU🇪🇺;
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Chris <ithinkiam@gmail.com> Wrote in message:

Dave Royal <dave@dave123royal.com> wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again. >>>>> I carved out a sane workflow inside an OS that keeps trying to turn into >>>>> iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!) >>>>
Windows and Linux can easily open HTML books stored in custom top-level >>>> hierarchies, even if the books contain tens of thousands of pages & jpegs. >>>>
Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
top-level POSIX folders such as /storage/emulated/0/0000/books/book1/.

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them
with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as >>> an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation

It may be published as html, but nowadays most documentation is *written*
in Markdown or similar dialect. With Markdown it's very easy to export into different formats like html, docx or pdf. There's no need save the book in html.

Indeed. That rust doc is written in markdown with svg images. They
use mdbook to convert that to html. mdbook may be able to produce
epubs - if not there's probably a converter.
--
Remove numerics from my email address.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.mobile.android

Carlos E. R. <robin_listas@es.invalid> wrote:

On 2026-07-08 19:51, Chris wrote:

Carlos E. R. <robin_listas@es.invalid> wrote:

On 2026-07-05 15:48, Dave Royal wrote:

"Carlos E. R." <robin_listas@es.invalid> Wrote in message:

On 2026-07-05 05:57, Maria Sophia wrote:

Maria Sophia wrote:

I finally forced Android 16 to behave like a real operating system again.
I carved out a sane workflow inside an OS that keeps trying to turn into
iOS, and I did it without surrendering my /0000 Unix /usr/local philosophy.

SUMMARY (Linux users added because it was Linux to the rescue this time!)

Windows and Linux can easily open HTML books stored in custom top-level >>>>>> hierarchies, even if the books contain tens of thousands of pages & jpegs.

Unfortunately, Android 10 through 16 cannot open HTML book stored in custom
top-level POSIX folders such as /storage/emulated/0/0000/books/book1/. >>>>>

I don't know what are "books" in this context.

If you mean electronic books, for me they are epubs, and I handle them >>>>> with Calibre.

https://www.gutenberg.org/ebooks/79019

I see html format is available, but I see no reason to use it, unless as >>>>> an intermediary to transform to something else.

Quite a lot of technical documentation is published as an html
'book'. This for example:
https://doc.rust-lang.org/book/

Historically html is a dialect of sgml, which was designed for
documentation

Ok...

Heh, they charge 45$ for the epub version.

No ZIP that I can see :-?

I would have to download using wget, and this tool modifies the links so >>> that they are correct for your local installation.

I wonder if Calibre can convert that to epub.

No need. If you go to the github you can download the source and build it
in whatever format you want.

Ah. Right. Did not occur to me, but in the past I had little luck with
doc building.

It is getting easier, especially with the likes of pandoc. This rust manual does require a few dependencies, however.

--- Synchronet 3.22a-Linux NewsLink 1.2