Develop Reference

Creating a single Firefox extension compatible with both desktop and Android

I developed a simple Firefox extension that fully works on Firefox for desktop computers. The extension uses a few SDK elements which are incompatible with Firefox for Android, likePanel, making it incompatible on Android.
I created two separate versions of the extension - one for desktop computers, and another one without the incompatible SDK elements which is compatible with Android. Everything works, however when I came to submit both extensions to the Mozilla AMO they were rejected and I was asked to consolidate them into a single extension.
How can I create a Firefox extension which uses desktop-only SDK elements on desktop Firefox and does not use them on Firefox for Android?

I ended up researching the issue and decided to write a blog post about the solution: http://blog.danielmittelman.com/2014/12/developing-firefox-add-ons-with-desktop-and-android-compatibility/
Here's the gist of it: There are SDK elements like panel or ui which are explicitly incompatible with Android. Ensuring compatibility with Android requires 3 steps:
1) Using only necessary Android-incompatible SDK elements (what you don't need - don't use)
2) Identifying the platform and using conditional statements to enable or disable potentially incompatible code
3) Creating and/or running the add-on using the --force-mobile flag of cfx

Given that you already have completely different versions for desktop and Android, you should be able to use the use the [flags] in your chrome.manifest to provide a different directory for the content, or other type of entry, based on the application ID using the application=app-ID flag. The application ID is different for Firefox for Android and Desktop Firefox.
The flags are explicitly there for you to be able to have different content based on the application (e.g. desktop/Android), the version of the application, the OS, the OS version, etc.
Example chrome.manifest entries would be:
content myAddon chrome/content-desktop/ application={ec8030f7-c20a-464f-9b0e-13a3a9e97384}
content myAddon chrome/content-android/ application={aa3c5121-dab2-40e2-81ca-7ea25febc110}
In the above example the URLs referencing chrome://myAddon/content would come from the chrome/content-desktop/ directory for desktop Firefox and the chrome/content-android/ for Firefox on Android.
If you have content that is shared between applications, you could have an entry like:
content myAddonShared chrome/content-shared/
Because you are using the Add-on SDK, you may have a bit more trouble doing this. I suspect that there is no way to set cfx up to provide such entries, and that you will have to make them manually.

Trigger.io Local Resource Access on Android 4.4

I have a very simple HTML5 app written with trigger.io that fails running under Android 4.4 with errors stating that local content cannot be accessed. Example:
E/AndroidProtocolHandler( 2236): Unable to open content URL: content:////io.trigger.forge9aee7db8338b11e4b77d1231392b77b0/src/images/connect4.jpg
The same code works find under Android 4.3. This applies to all local content including images, CSS and JavaScript. All resources are referenced with relative paths such as "images/image.jpg".
My best guess is that there is an access policy change in newer versions of Android OS but I cannot figure out the details. I have made sure that nowhere in the code attempts to access external resources.

Antoine van Gelder was incredibly helpful on this. His diagnosis was absolutely correct that jQuery Mobile is rewriting the URLs for resources which causes newer versions of Android's Chrome Webview to fail when accessing resources. The generated URLs contain quadruple slashes after the protocol like this:
content:////io.trigger.forge9aee7db8338b11e4b77d1231392b77b0/src/resource.png
The extra slashes cause Webview to fail. Possibly some excessive checking for correctness or a security implication?
Antoine's suggestions of using older versions of jQuery Mobile or building a custom jQuery Mobile without Base Tag will probably work in some circumstances though neither was quite sufficient in my case. Particularly, removing Base Tag also removes some other functionality I needed.
An alternative approach is to make a minor hack to jQuery Mobile. For version 1.4.3 I did the following:
Edited an un-minified version of jQuery Mobile's javascript
Modified the getLocation function:
Save the return value to a temporary variable
Modify the temporary variable by removing quadruple slashes.
I used something very specific and restricted to the "content" protocol: "retVal = retVal.replace("content:////","content://");"
Return the fixed temporary variable

It looks like, starting with v1.3, jQuery Mobile are rewriting the URL's in your document which breaks the Chrome Webview's access to files in the app sandbox.
You could try filing a bug report with the jQuery Mobile devs but to sort this out in the short term your best options are probably one of:
1) Fall back to jQuery Mobile 1.2.1
2) Build a custom version of jQuery Mobile which excludes some navigation features. (Go to download builder (http://jquerymobile.com/download-builder/), scroll down to "Navigation" and de-select the "Base Tag" module)

This should be fixed in JqueryMobile 1.4.4.

Can 4.0+ RTL library for WebView be packaged with apk for 2.2~2.3?

We wanted to develop a web search app for Android 2.2+, and the language we're dealing with is Arabic script (RTL) based. We are using WebView as the rendering view.
So far only devices with Android 4.0+ (and some Sony phones whith 2.3) displayed the text correctly. But Android 2.x devices still consists a large part of our web users, we needed the same Arabic RTL support in Android 4.0 be availabe with our app.
To be clear, the mentioned Arabic support is not only the direction:rtl (which can be achieved with CSS), but more importantly a letter joining problem: most letters automatically change accroting to the previous and next letter when displayed.
On Windows, since 2000 version, there is a system shared library USP10.dll to handle the process. And applications have the file in their folder, would have the same support even on older Windows 98 systems.
Based on my research on the web, on android there are libicuuc.so and framework.jar to do the similar job.
My question is:
Since Android 4.0+ has the ability to hanlde the letter joining, is it possible to package the corresponding library with the apk to support Arabic in WebView?
If so, how (e.g where to put the file, and any code to add to activity)?
Many thanks in advance.

You can't add newer library for old sdk's. Old sdk's depend upon old java libraries.

Use Chrome as render engine for Android webview

I found this question very similar to what I need but I need chrome. Because of many reasons android webView (as I discussed here ) is not compatible with my application's requirements.
So are there any ways to Use Chrome as render engine for Android webview

This is coming as the default in Android 4.4 KitKat. See https://developers.google.com/chrome/mobile/docs/webview/overview

Here is a proof of concept for a view that uses the Chromium code and has a WebView-like API.
https://github.com/pwnall/chromeview
Make sure to read the Issues section in the Readme. This is merely a starting point, it's not ready for production use.

In addition to #Hyangelo's answer, if anyone needs to support Chrome for Android versions 4.0-4.3, you can use crosswalk.

how to embed an SVG enabled webkit webview in an Android app?

Is there a way to embed a customized webkit engine in an app to add a WebView with SVG support ?

The according Bug Entry mentions some android core dependencies which seem not-so-easy to replace, not sure if all of that could be included in a built to provide exactly a webkit webview with your app.
However, in general one can use another library project to be referenced and included on compilation. And then there is a way to include other JAR files, a way to convert an existing project into a library as well as even a way to butcher an .apk and get the code out (which again you can turn into a libary).
Never done it, but in theory, get a library, .jar or .apk of the browser you want to bundle (as mentioned the beginning seems not the best candidate), look into the original code what is done to instantiate that browsers view in an activity - and off you go.
Would love to hear when you or anybody else has accomplished to do such a thing, i couldn't wait to see if we could bundle it with multitouch enabled (another big drawback in 2.x) for multitouch on the android stock browser on 2.x devices i started a polyfill project out of desparation (which works surprisingly well, but is also way simpler than emulating a complete SVG interpreter), so for matter of SVG and providing the best browser runtime for the job, this would be great.
P.S. There is one completely different workaround depending on what you want to do with SVG. If it's just some small stuff to fill on the screen at times you might check google for "svg polyfill" which leads to a myriad of solutions - i couldn't recommend one straightaway, as those implementations are so different that you should evaluate them with your actual app.