tag:blogger.com,1999:blog-8214401912480503366.post7118135115951726943..comments2023-08-10T13:35:15.093+02:00Comments on My life with Android :-): Direct service invocation considered harmfulGabor Pallerhttp://www.blogger.com/profile/14307475522972458932noreply@blogger.comBlogger9125tag:blogger.com,1999:blog-8214401912480503366.post-22054728113042622482010-08-24T01:58:37.460+02:002010-08-24T01:58:37.460+02:00Hi Francois, I was thinking about the same problem...Hi Francois, I was thinking about the same problem. I can call music service in google and htc droids because the aidl is known, but how to call service methods on samsung?<br />I can't test it, but I have the following idea:<br /><br />1/ first, you have to know the package and class name for the service (otherwise you cannot call it). That should be easily accessible from the list of running services, if you have the device.<br /><br />2/ you get IBinder instance<br />3/ call getInterfaceDescriptor()<br />4/ get IInterface instance by passing descriptor to queryLocalInterface<br /><br />When you have IInterface instance, you would usually cast it to the interface created from aidl but I think you can also use reflection (getClass().getMethods() etc.) to access all public methods and call them.<br /><br />I think that should work.sulthanhttps://www.blogger.com/profile/09271475849919965225noreply@blogger.comtag:blogger.com,1999:blog-8214401912480503366.post-18663177113316294492010-07-18T20:01:48.378+02:002010-07-18T20:01:48.378+02:00Hi,
I'd like to know if there is a way to disc...Hi,<br />I'd like to know if there is a way to discover public interface of an existing service (without having the source code).<br />I already made some AIDL for stock music service, but I'd like to create other non open source music player (Samsung, Sony ...).<br />Is there a way to do it ?<br />Thanks,<br />FrancoisUnknownhttps://www.blogger.com/profile/05549976271950487677noreply@blogger.comtag:blogger.com,1999:blog-8214401912480503366.post-49383492551775687242010-07-13T22:05:30.943+02:002010-07-13T22:05:30.943+02:00@karni - In the spoken version of the presentation...@karni - In the spoken version of the presentation, I said there is no need to use RPC to talk to different components inside your own application.<br /><br />"Do not use" is meant in the context that single APK distribution is the norm, which allowed me to direct the minority of exceptions towards an AIDL specific presentation (see slide 19) that was going on later that day. ;-)<br /><br />I can name three occurrences where I've met teams using AIDL inside their own apps, suffered performance problems, and argued that direct communication is impossible.Mark Bradyhttps://www.blogger.com/profile/05713153273074430397noreply@blogger.comtag:blogger.com,1999:blog-8214401912480503366.post-36067886586812531332010-07-13T03:02:05.546+02:002010-07-13T03:02:05.546+02:00@whitemice You write in your presentation *do not ...@whitemice You write in your presentation *do not use* . Well, *by default* doesn't mean it's the case. How do you perform binding to a (local??) service from 3 different applications? Let's say it's an RSS feed fetcher of some sort.karnihttps://www.blogger.com/profile/08867996061726418344noreply@blogger.comtag:blogger.com,1999:blog-8214401912480503366.post-71879450568701913152010-07-12T23:02:51.899+02:002010-07-12T23:02:51.899+02:00AIDL is an unnecessary overhead as *by default* al...AIDL is an unnecessary overhead as *by default* all your components run in the same process. This comes as a shock to many Android developers, which is why I put some code examples together for this presentation:<br /><br />Architecture your Android Application<br />http://tinyurl.com/34uy9nz<br /><br />You now only have to worry about if your component is still there when you try and communicate with it. ;-)Mark Bradyhttps://www.blogger.com/profile/05713153273074430397noreply@blogger.comtag:blogger.com,1999:blog-8214401912480503366.post-1597356647328463702010-07-12T22:19:42.932+02:002010-07-12T22:19:42.932+02:00Indeed, it is valid. As long as the Service runs i...Indeed, it is valid. As long as the Service runs in the same process as the application. If you define android:process="some_tag" then the process will run in a separate thread and then you have to use AIDL for IPC. At least, that's how I understood the docs.karnihttps://www.blogger.com/profile/08867996061726418344noreply@blogger.comtag:blogger.com,1999:blog-8214401912480503366.post-9902650650470266212010-07-12T22:10:18.660+02:002010-07-12T22:10:18.660+02:00I agree with Mark. Gabor, you are thinking about S...I agree with Mark. Gabor, you are thinking about Services only in the remote setup. If used locally, the extensive aidl mechanism is not needed.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8214401912480503366.post-78623510582537137942010-07-10T17:49:50.896+02:002010-07-10T17:49:50.896+02:00Thanks for that, Mark. I thought I'd seen this...Thanks for that, Mark. I <i>thought</i> I'd seen this mentioned in the API docs. Is there actual published statement that this is a valid pattern? Perhaps some assurance that the non-process separation will not be abandoned in the future?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-8214401912480503366.post-25544192376899925952010-07-09T21:40:49.082+02:002010-07-09T21:40:49.082+02:00Considering that this is the local binding pattern...Considering that this is the local binding pattern endorsed by the core Android team and demonstrated in their SDK samples, it seems odd that you consider this to be a "hack".<br /><br />http://developer.android.com/resources/samples/ApiDemos/src/com/example/android/apis/app/LocalService.htmlMark Murphyhttp://commonsware.comnoreply@blogger.com