Problem: The Android distro provides no way for me to view local
content in HTML format, specifically content I copy onto the memory card.
Every other web browser in the world can show content on the local
machine, so this is a bug.
Version: Android 1.0 (pre-Cupcake).
Background: In numerous forum postings users complain about the lack
of file URLs in Android. This one: http://groups.google.com/group/android-
developers/msg/45977f54cf4aa592 by Luca Belluccini (2008-08-24) has a
comment from developer Megha Joshi saying that file:// was formerly
supported but was suppressed due to an unspecified security threat. (I'm
surprised that the keywords "file url" yield nothing on this topic in the
bug search page.)
Rationale for local content: On the Nokia N810 I spend more time
using local content than all other activities combined, but this is not
possible on the G1 under Android. I use these classes of local content:
* A local start page so the browser starts with something reasonable even
if the net is unavailable.
* Downloaded issues of journals (scientific and professional magazines).
* E-books in HTML format: software documentation, and entertainment.
* Music and photo gallery with my platform-independent HTML indexing.
Other users report that their major use of the handheld computer is
for field maintenance manuals or product sales catalogs, to be used at the
customer's site independent of flaky or nonexistent cellular or WiFi
connections.
While some people only use local content managed by the distro's pre-
made applications, such as the music player's library module or the photo
indexer, I think a lot of people, not just myself, need this capability to
copy local content onto the memory card and use it, beyond what the
developers planned.
Workarounds:
* Alternate browsers: Steel and Opera Mini share infrastructure with the
Android browser, so also lack file:// URLs. Useless.
* Local webserver: While I use this solution on my laptop and desktop
machines for web development, a webserver on a phone seems kind of over
the top. Nonetheless I tried i-jetty ( http://code.google.com/p/i-
jetty/ ). It works, though it's slow, but I would have to create a plugin
to access /sdcard, so I deferred this solution, trying first something
with a more attractive learning curve.
* Symbolic links in /data/data/com.android.browser: I could not figure
out any such link that was useful.
* Custom content provider: This blog post: http://www.techjini.com/
blog/2009/01/10/android-tip-1-contentprovider-accessing-local-file-system-
from-webview-showing-image-in-webview-using-content/ shows how to do it.
Supposing the app's D-Bus path is com.android.fileurl, a URL of content://
com.android.fileurl/android-asset/sdcard/whatever.html would cause the app
to be executed, and it would open the indicated path and pipe the content
to the browser. People say that this is the natural way to do things in
Android. However, to create this app I would need to learn how to use my
new copy of the SDK and Eclipse, learn Java, and learn how to pack up the
result in an APK file with proper signatures so the package installer will
accept it. So I deferred this solution also.
* Google Gears: My use case is exactly what Gears is intended to handle:
a local copy of content that could have been used on the net. First I
made a symbolic link from /data/data/com.android.browser/gears to a
directory on the memory card, since there isn't enough room in main flash
for even one of my items. I read the Gears API docs, shamelessly stole
Javascript out of the demo, wrote a script (attached) to gearify a journal
issue, and set up the master copies. It works -- actually it seems to
work well, even in "airplane mode", which is the whole point of this
kludge.
So I have a solution for my requirement. But could I ask my wife, an
experienced user but not a programmer, to do any of these workarounds? I
don't think so; there is no effective workaround for an ordinary user.
What I Would Like the Developers to Do:
* Revert the patch; bring back the file:// URL. And of course deal with
the security issue (whatever it is) in a less destructive way.
* Until the repaired browser libraries can be distributed to the users,
post on the Android Market the "fileurl" app described above. The reason
I don't commit to doing this myself is, I think this is not the best
project to be my first try with the SDK, whereas someone on the browser
development team could probably put together a professional quality
package in an hour or two.
* Quite a number of people complaining about the lack of file:// were
developers who wanted to show static pages from their app's asset
directory. While the data: and content: URI schemas were offered as
solutions, it's easy and natural to make a static page, while the
nonstandard methods present a barrier to the developer. I've noticed that
a lot of apps lack help or "about" pages, and I suspect that the
developers don't want to re-invent the wheel to make those pages happen.
I would suggest that library initialization (not the app itself) should
set the app's base URL to file:///data/data/name.of.app, and then if the
app sent a relative URL to Webview such as "help.html", the file would be
found, with no need to hardwire the app's residence directory in the app's
own code. (I may well have the directory wrong: I do need to read docs
and learn how to build an Android app.)
Conclusion: I love my G1 phone, which is doing everything my N810 did
and more, now that I have a workaround for the file:// URL bug. And I
like the Android browser better than Micro-b for Maemo. But few users can
do what I did as a workaround, and the bug needs to be fixed the right way.

Issue 36907544

Links (8)

Issue metadata