Thanks for the insights, Mark. Am I right in assuming that there is no way to forceably stop a misbehaving thread within an Android application short of killing the process that owns the thread? My problem is that I'm loading java- based plug-ins (not ARM binaries) into my framework dynamically (using OSGi) and running each plug-in on its own thread. My framework configures, starts and holds a reference to each plug-in thread; however, if a plug-in misbehaves (i.e. keeps running even when told to stop), my framework is unable to forceably kill the thread its running on. Deprecated Thread methods for this purpose (e.g. 'stop') are not implemented in Android, so I seem to be left with flags and interrupts, which can be easily ignored accidentally or on purpose.
>From what you wrote, it might be possible for me run my framework in one process and my dynamically loaded plug-ins in a second process. That way, if I need to kill a misbehaving plug-in, I could kill the second process, mark the plug-in as problematic, and uninstall it prior to restarting the second process. Of course, this is a heavyweight approach, and it would be much simpler if my framework could simply forceably stop a misbehaving thread. Any ideas or tricks in this regard? Cheers, DCA On Jul 16, 1:26 pm, Mark Murphy <mmur...@commonsware.com> wrote: > On Sat, Jul 16, 2011 at 7:15 AM, DCA <onl...@dcarlson.info> wrote: > > however, do applications with multiple processes share the same memory > > space, or is AIDL required to communicate between components running > > in a separate process, even though they are both part of the same > > application? > > They do not share the same memory space, by definition. > > > Can an application > > "launch" additional processes arbitrarily, or is there some Manifest > > configuration necessary? > > If you are just trying to run some ARM binary that you copied onto the > device, forking a process via standard Java should work. Though an ARM > binary will only work on ARM devices, not x86 (e.g., Google TV) > devices. > > If you are expecting a Dalvik VM and Android components to be in the > other process, you have to add an android:process attribute to the > manifest to indicate that such-and-so component should run in another > process. > > Neither of this is a good idea, because extra processes take up extra > RAM. A well-written Android application usually uses zero processes > (i.e., is not running), and only uses one process when the user asks > for it to run. > > > Also, what about filesystem access - i.e. can > > each process in an single application access each others' files? > > They will all run as the same user account and have the same "home > directory" (i.e., getFilesDir()). > > > My > > end goal is to be able to isolate and possibly terminate misbehaving > > plug-ins that have been loaded at runtime using OSGi. > > IMHO, getting OSGi to work well without custom firmware may be difficult. > > -- > Mark Murphy (a Commons > Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy > > _The Busy Coder's Guide to Android Development_ Version 3.6 Available! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
