1414615 - Support Native Messaging on Android

Status: RESOLVED DUPLICATE of bug 1632903

(WebExtensions :: Android, enhancement, P5)

Description

[Tatsuyuki Ishi]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171102181127

Steps to reproduce:

One of native messaging's use case is password managers, and they're just as important on Android. I propose here to implement support for it. (Chrome doesn't support addons on mobile, so it doesn't matter anyway.)

Some ideas in detail:
- Two ideas for authorization:
  * writing to shared storage
  * launching a Firefox activity from 3rd-party app and prompt the user
- Messaging itself should use a bound service, and "piping" should occur through binder. To make it similar to the desktop API, it should be kept to be a simple text read-write interface.

Comment 1

[Mike Conca [:mconca]]

I'm going to take this out of the design-decision queue for the simple reason that Mozilla is moving away from the current implementation of Firefox for Android (Fennec) towards an Android browser based on the new geckoView library.

https://wiki.mozilla.org/Mobile/GeckoView

That major architectural change will cause all WebExtenion API for Android to be reviewed.

Comment 2

[inetic]

Could someone please comment on the viability of the Native Messaging API in future FF Android releases?

We're considering the option of forking the code and trying to enable this feature until it's officially in the current or the next (GeckoView based) FF. As such, we'd greatly appreciate a word of warning about possible traps that lay in front of us. For example:

* Is it likely that the interface will be (approximately) identical to the one on FF/Desktop?
* Are there known problems with trying to spawn a subprocess identically as you do on FF/Linux? (see below for details)

Android being essentially a Linux system, it seems plausible that spawning a process and communicating with it using std io should be possible.

I've been digging in the code today (first time looking into Mozilla's codebase) and found this:

https://dxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/NativeManifests.jsm#49

Which seems to suggest that if we were to continue with the "linux" code path on an actual Android, we'd get a failure somewhere further down. Is that the case?

Just to be a bit more throughout in this description, the spawning of the process seems to happen here

https://dxr.mozilla.org/mozilla-central/source/toolkit/components/extensions/NativeMessaging.jsm#90

And the Subprocess class seems to be defined somewhere here

https://dxr.mozilla.org/mozilla-central/source/toolkit/modules/subprocess

I haven't yet found exactly yet where the process is spawned, but skimming through the `*_unix.js` files, those native commands look pretty standard. Or perhaps I'm missing something?

Comment 3

[Tatsuyuki Ishi]

(In reply to inetic from comment #2)
> Could someone please comment on the viability of the Native Messaging API in
> future FF Android releases?
> 
> We're considering the option of forking the code and trying to enable this
> feature until it's officially in the current or the next (GeckoView based)
> FF. As such, we'd greatly appreciate a word of warning about possible traps
> that lay in front of us. For example:
> 
> * Is it likely that the interface will be (approximately) identical to the
> one on FF/Desktop?
> * Are there known problems with trying to spawn a subprocess identically as
> you do on FF/Linux? (see below for details)

Pardon me, but I think apps in Android are isolated so we need much platform
specific interface on this?

Yes you can spawn a subprocess, but only if it's a binary inside your app.
Files in the external storage are not executable, and even if it did you still
can't access other app's data.

You need to use the native Android mechanism to build a Service to communicate
with. We can still use the stream oriented interface, but not stdin/stdout. The
main obstacle here is to build a protocol to interact with other apps.

Comment 4

[inetic]

> Pardon me, but I think apps in Android are isolated so we need much platform
> specific interface on this?

I am unsure as well. From your first post here, I see that your main use case is to communicate with other Android apps. Our use case is different. We have an Arm binary (programmed in C++ with no Java) and we need FF/Android to communicate with it.

Ideally, we'd just use the `js-ctypes` interface, but we see and understand why Mozilla deprecated that approach

https://blog.mozilla.org/addons/2017/01/24/preventing-add-ons-third-party-software-from-loading-dlls-into-firefox/

> Yes you can spawn a subprocess, but only if it's a binary inside your app. Files in the external storage are not executable,

Is it really the case? There seem to be a project which showcases how one can download a binary from the internet, execute it and communicate with it using Unix pipes (I have not yet tested it though):

http://gimite.net/en/index.php?Run%20native%20executable%20in%20Android%20App

> and even if it did you still can't access other app's data.

This isn't required for our use-case, but I see how that would be important for you and many others. However, I _think_ that once the Unix process/pipes interface was in place, one could then use it to build binaries that can communicate with the rest of the Android apps and access their data. Doing it this way may be a burden for non C/C++ developers at the beginning, but over time, OSS libraries could be created to ease this task.

Doing it the other way however (the way you propose if I understand it correctly), our extension would need to install a new APK with which FF/Android would communicate using the native Android mechanism. AFAIK, for FF/Android to be on Google/Play, it cannot serve as a kind of marketplace to compete with Google/Play and I _think_ that implies it cannot directly install APKs. So after downloading our extension from FF's add-on directory, we'd need to somehow redirect the user to Google's play store to download the rest. Similarly, even if the user was willing to do this, uninstalling FF/Android wouldn't automatically uninstall this new extension APK. Both of these seem like a bad UX.

Comment 5

[Andrew Swan [:aswan]]

inetic, its not clear to me what you're proposing.  We will not be implementing a system where native code is shipped as part of the extension.  Any viable solution here would entail installing the native application outside of Firefox (eg from the Play store).  I'm not all that experienced with the Android platform, but I think that communication using something like intents would fit more naturally into the way Android manages process lifecycles.  I suspect that a new Android-specific API for intents would work better than trying to fit something onto the existing desktop-centric API.

Comment 6

[inetic]

> inetic, its not clear to me what you're proposing.  We will not be implementing a system where native code is shipped as part of the extension.

Ah, it seems I have misunderstood the extension's purpose then. I've been eyeing how to write extensions to FF only in the last four days and after reading this post

https://blog.mozilla.org/addons/2017/01/24/preventing-add-ons-third-party-software-from-loading-dlls-into-firefox/

my understanding was that instead of an extension carrying a .so/.dll with it, it would carry an executable with the benefit of not crashing the entire FF if something goes wrong. But now that I think about it, was it ever possible to pack a .so/.dll with an extension?

In either case, given that you have no plans in shipping binaries with extension, my proposal is moot and I apologize for the noise.

Starting another app with an Intent and communicating with it using android.os.Binder (as mentioned by Tatsuyuki) sounds reasonable. That is, apart from the awkward user experience with double install/uninstall as mentioned above, but without shipping native code with an extension I don't see a good solution to that.

Comment 7

[Tatsuyuki Ishi]

Two things. First, the double install experience is already how native messaging works on desktop, so I guess that is not much a burden.

Second, have you considered WebAssembly instead of native extensions?

Comment 8

[inetic]

> First, the double install experience is already how native messaging works on desktop, so I guess that is not much a burden.

To me, providing a service through a browser is great mostly because it provides least resistance to users who want to try it. If the user has to install "something", he/she may as well just install an app (desktop or mobile) and use that directly. As such, it's my opinion that having to explicitly install extension apps on desktop is unfortunate as well.

> Second, have you considered WebAssembly instead of native extensions?

Our use case is that our library/app uses other libraries that are written in C/C++ (BitTorrent, I2P,...), golang (IPFS),... which all compile to native code. Rewriting them all would be impossible for our team. On top of that, some of the libraries require access to UDP sockets, which I don't think can be accessed from WebAssembly (or am I mistaken?).