[Fso] Android port of FSO middleware?

[H. Nikolaus Schaller]

HI,

> Am 22.12.2016 um 02:02 schrieb Denis 'GNUtoo' Carikli <GNUtoo at no-log.org>:
> 
> 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.

There is a free and working RIL for the GTA04 (and other AT based devices)
so I wonder why FSO would be good for at all. IMHO it only adds a lot of
complexity but no new functions.

> 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.

Would be interesting to know.

BR,
Nikolaus