Reading byte data from a content provider through openInputStream() is part of the public API. It is important, very important: this is not only about a single app, it's about a plugin loading and discovery protocol. Indeed, if something breaks in a future Android release then it would break many hosts and plugins.
Your idea would be ideal, but how can we be sure that it will continue to work in the future? Apps directly accessing other apps' files.. That sounds dangerous. And if that's possible, then I wouldn't be surprised if it stops working some day for security reasons. Also, if a plugin package vendor wants to use forward locking (or a future equivalent), that's his choice after all. I'm especially worried about this sentence which mentions permissions: http://developer.android.com/intl/fr/guide/topics/providers/content-providers.html#creating "The ContentResolver [...] because it has higher permissions than a client, it should be able to access that file directly and return a read wrapper for the file to the client." Olivier On 09/10/2010 03:48 AM, Chris Stratton wrote: > I think you would only need to copy it if the source app is forward > locked. While you can't explore /data/data you can generally read > the contents of package included files below there if you are told or > can guess the subdirectory name. So you should be able to use an > intent to find an installed library provider and have it reply with a > full path to the .so which you would then load. > Olivier Guilyardi wrote: >> Retrieving an .so from an external app should be very easy, by using a >> content >> provider and ContentResolver.openInputStream(). It gives you an InputStream >> from >> which you can read the shared object, to store it locally. >> http://developer.android.com/intl/fr/guide/topics/providers/content-providers.html#creating >> >> The only catch is that, if you store the .so on the sdcard, then you won't be >> able to dlopen() it because the sdcard is mounted noexec (and storing the >> .so on >> the sdcard may be a security issue anyway). You need to store the .so in the >> internal memory, that is somewhere in your app's data dir. >> >> Loading shared objects with dlopen() is very reliable in my experience, and >> it's >> not discouraged by the Android team AFAIK. >> >> Olivier >> >> On 09/10/2010 12:11 AM, Chris Stratton wrote: >>> I think if you can read an .so you can load it. Had thought you >>> needed execute permissions but found an example of a lib in an app >>> without. I need to explicitly try it from another app for a different >>> purpose anyway. >>> >>> >>> niko20 wrote: >>>> I'm still not seeing how you could pass audio data to the plugin with >>>> low latency buffering. I'm not sure if an app can "load" an .so from >>>> another app so to speak. >>>> >>>> -niko >>>> >>>> On Sep 9, 12:54 pm, Kiall Mac Innes <[email protected]> wrote: >>>>> You should try the android developers list rather than a general >>>>> discussion >>>>> list for this kinda thing... >>>>> >>>>> >>>>> >>>>>> Hi everyone, >>>>>> I have a sound recorder and editor app on the market, and I'm currently >>>>> working >>>>>> on audio effects, such as reverb, compression, etc.. >>>>>> For this purpose I will very likely use LADSPA plugins, which are in >>>>>> their >>>>> vast >>>>>> majority GPL licensed. This is a bit controversial, but according to my >>>>>> googling, it is quite ok to load GPL plugins into a closed source app. >>>>> But, the >>>>>> plugins really need to be plugins, that is distributed as separated >>>>> packages. >>>>> >>>>>> That said, this isn't only about legal stuff. I am seeing great >>>>> opportunities >>>>>> for the Android ecosystem concerning such audio plugins. I think that the >>>>> high >>>>>> interoperability abilities between apps (through intent filters, content >>>>>> providers, etc..) is a great strength of the platform. >>>>>> Therefore, if us developers were able to agree on some particular audio >>>>> plugin >>>>>> paradigm and discovery system, the Android audio world could become very >>>>>> attractive to both users and developers. >>>>>> In my current idea, a package (= an app on the market) may contain >>>>>> several >>>>>> plugins, and there might be several packages from various vendors. Here, >>>>>> discovery of the plugins by a given host should be quite easy to achieve >>>>> by >>>>>> using queryIntentServices() where each plugin package would expose a >>>>> service >>>>>> with a pre-defined intent filter. A content provider could also be used >>>>> for >>>>>> retrieving information about the bundled plugin. >>>>>> Now, in regard to loading and communicating with a plugin, there are many >>>>>> possibilities, some very complex. Right now, I am thinking about a very >>>>> simple >>>>>> first mechanism, where a host can retrieve LADSPA shared objects from a >>>>> plugin >>>>>> package through a content provider exposed by the said package. This will >>>>> allow >>>>>> for high performance by loading the .so in my native audio engine. >>>>>> This is a very simple mechanism, though with some work, I believe that it >>>>> should >>>>>> be possible to distribute and load plugins which come with a UI, just as >>>>> desktop >>>>>> users do with VST instruments. >>>>>> That said, what do you think about the general idea? Would some of you be >>>>>> interested by such an audio plugin system? >>>>>> -- >>>>>> Olivier >>>>>> -- >>>>>> You received this message because you are subscribed to the Google Groups >>>>> "Android Discuss" group.> To post to this group, send email to >>>>> [email protected]. >>>>>> To unsubscribe from this group, send email to >>>>> [email protected]<android-discuss%2Bunsubscribe@ >>>>> googlegroups.com> >>>>> .> For more options, visit this group at >>>>> >>>>> http://groups.google.com/group/android-discuss?hl=en. >>>>> >>>>> >>>>> >>>>> > -- You received this message because you are subscribed to the Google Groups "Android Discuss" 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-discuss?hl=en.
