[Fso] Android port of FSO middleware?

Denis 'GNUtoo' Carikli GNUtoo at no-log.org
Thu Dec 22 02:02:34 CET 2016


On Mon, 7 Nov 2016 10:13:01 +0100
"Dr. Michael Lauer" <mickey at vanille.de> wrote:

> Dear Alastair,
Hi,

Sorry of jumping in late, due to technical issues I also don't have the
original mail to quote.

> first off, sorry for the long delay in answering you. Since this
> mailing list is pretty quiet, I completely overlooked it.
> > I’m interested in what members of this community think about the
> > feasibility of an Android implementation of the FSO middleware? The
> > way I imagine this would work is that an Android background service
> > would be running on the device, which would register listeners for
> > various android “intents” and also maintain a d-bus connection. It
> > would then ferry requests between the two systems, turning intents
> > into d-bus signals and vice versa.
Porting a GNU/Linux stack like FSO Android is a really good idea:
It will bring free software support for a lot of hardware, including
the GTA04. It might be really interesting to use with Replicant.

If that stack is used, adding hardware support in also makes
sense as it would work on Android, GNU/Linux and potentially other
configurations.

As far as I remember the FSO dbus daemons can be used independently
from each other which is good.

Now, I have almost no experience in writing Android applications, but
I've a good knowledge of the underlying hardware adapation architecture.

While dbus is the way to go to interface with FSO, I don't get the point
of using intents as the Android interface.
Let's say you write a dummy android background service that prints
strings to the debug log when it receive an intent:
- Would you be able to implement all the telephony interface at the
  intent level?
- How would the user experience be with that, you probably would need
  to choose which intent backend you want to use when making a call,
  but what will happen when receiving a call?
  - If you have two backends
  - If you remove parts of the Android framework, will you be able to
    cope with that?
    Let's say you remove rild, do you also need to also remove the audio
    library and the GPS library(can probably easily be deactivated) ?

We already have a case where Android and FSO shares code in order to
work on the same devices, however it's limited to the modem support
only.

Several smasung smartphones/tablets are supported by both FSO and
Replicant. The architecture is the following on Replicant:
[Android framework] <-> [rild] <->[libsamsung-ril]<->[libsamsung-ipc]
And on FSO:
[fsogsmd]<->[modem plugin]<->[libsamsung-ipc]

- The Android framework and the rild probably weren't modified for that.
- libsamsung-ril was written by a Replicant developer (Paul
  Kocialkowski) and is Android specific
- FSO's modem plugin is FSO specific.
- libsamsung-ipc is used by both Replicant's libsamsung-ril and FSO's
  modem plugin.

In Replicant there is also some interaction between the ril(probably
trough libsamsung-ril) and the audio library.

Since I didn't design all that and were very marginally involved in
samsung-ril/samsung-ipc/FSO's modem plugin I don't know why this
architecture was chosen.

Denis.


More information about the Fso mailing list