HTC G1 Cellphone
Bug Report: File URL

Bug report was posted on 2009-04-17: Issue number 2454.

Summary: Cannot view html on sdcard because no file url

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.