Oh one thing I am pretty sure about -- I -don't- think the RIL is intended to be used by anything except the higher-level phone stack. It is the abstraction between it and the underlying telephony system. You might want to think if you are just coming at this from completely the wrong position if you are trying to become an additional client of the RIL, rather than interacting with the high-level stack for whatever you want to do.
On Fri, Mar 27, 2009 at 9:48 AM, Dianne Hackborn <[email protected]>wrote: > I really don't know much about the telephony stack. I also doubt just > changing the IPC mechanism is a magic solution -- very likely the RIL is > designed to have one client. If you don't design for multiple clients > up-front, adding support for that in the future generally involves a fair > amount of rework. > > > On Fri, Mar 27, 2009 at 2:39 AM, [email protected] < > [email protected]> wrote: > >> >> Are there other reasons as well? My understanding of Binder service in >> Android is that it is a Service User and Service Provider model, that >> means for two way communication(specially from Service Provider to >> Service Users, in case of asynchronous notifications, callbacks etc, >> the Service User also has to start a service for receving these >> events,etc).I am just wondering about the possibility of two way >> communication between processes using Binder, can you comment on that? >> >> Regards, >> Ashutosh >> >> >> On Mar 17, 7:29 am, Dianne Hackborn <[email protected]> wrote: >> > Basically because that is how it was implemented. *shrug* And it was >> > written long before there was any Binder IPC facility. >> > >> > On Mon, Mar 16, 2009 at 1:47 PM, Videoguy <[email protected]> >> wrote: >> > >> > > Hi >> > > The communication between GSM stack and RIL daemon is done using Local >> > > unix socket instead of Binder ipc. >> > >> > > Why was it done like that? >> > > Are there any exceptions to when one can use Binder based ipc? >> > >> > > Thanks >> > > Videoguy >> > >> > -- >> > Dianne Hackborn >> > Android framework engineer >> > [email protected] >> > >> > Note: please don't send private questions to me, as I don't have time to >> > provide private support. All such questions should be posted on public >> > forums, where I and others can see and answer them. >> >> >> > > > -- > Dianne Hackborn > Android framework engineer > [email protected] > > > Note: please don't send private questions to me, as I don't have time to > provide private support. All such questions should be posted on public > forums, where I and others can see and answer them. > > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "android-framework" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-framework?hl=en -~----------~----~----~----~------~----~------~--~---
