Battle of the quotes, from: http://code.google.com/android/reference/android/app/Service.html
"Other application components running in the same process as the service (such as an Activity) can, of course, increase the importance of the overall process beyond just the importance of the service itself. " This is like trying to interpret the Talmud or something... ;-) On Nov 10, 6:12 pm, Mark Murphy <[EMAIL PROTECTED]> wrote: > dreamerBoywrote: > > Thanks for the reply, Mark (I recognize the name - I read your book.) > > Thanks! > > > I am trying to place a call with the Activity that may - but need not, > > have any graphical UI aspect to it. Launching an Activity appears to > > be the only way to place a call in Android 1.0. If the thinking of > > the API is to disallow any calls being placed in an automated fashion, > > it seems to me that there would be no need for ACTION_CALL - only > > ACTION_DIAL. > > In the ACTION_CALL documentation, it states: > > "Note: there will be restrictions on which applications can initiate a > call; most applications should use the ACTION_DIAL." > > So even if you can get past the NullPointerException, you may still not > be able to place the call. > > Now, probably it will work, as there have been recent tutorials > demonstrating that it works from an activity, but I could see where this > might get locked down sometime in the future. > > > I am also wondering if there exists within the exposed Android API, a > > way to hang up a call in an automated fashion. No appropriate intents > > exist - it seems the only remaining possibility is calling finish() or > > finishActivity(ACTIVITY_ID) on the Activity used to place or answer > > the call. However, there is nothing in the docs which actually states > > that. If I can get past my currently difficulty, I will definitely > > test it. > > You could putter through the source code to see how the in-call > application handles it. Again, whatever technique it uses is probably > not for public consumption, your mileage may vary, do not taunt Happy > Fun Android, etc. > > > I'll be reconfiguring the program to see if I can get different > > results - perhaps I missed something simple in the Manifest. However, > > a NullPointerException really does merit some explanation. > > Well, hackbod took a guess, and her guesses are pretty damn good. > > Is whatever Context represented by initiateCall "real"? For example, if > initiateCall is some Activity you instantiated yourself as part of this > automated , that may not be fully-formed (i.e., gone through the normal > lifecycle) and therefore may not be able to start other activities. > > I hate to be the bearer of bad tidings, since you read my book and all > ;-), but I'm not terribly hopeful you'll be able to place a call, > initiated by some remote application, automatically, without user > intervention. > > Or, to put it another way, if it works, it'll scare the crap out of me, > because there's all sorts of nasty things one can do with that technique. > > -- > Mark Murphy (a Commons Guy)http://commonsware.com > _The Busy Coder's Guide to Android Development_ Version 1.4 Published! --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en -~----------~----~----~----~------~----~------~--~---
