From Newsgroup: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

"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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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: alt.os.linux

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