Hi, Thanks a mill ! It's working.
One more question now - is there a way I can toggle the Intent filter in code (in run-time) ? What I am aiming at is adding this as a setting in my application, allowing the user to decide if he/she wants my app to replace the dialer for the PHONE button. If I declare the intent-filter in the AndroidManifest file - it's "hard-coded" there... TIA On Jan 12, 9:17 pm, "A T" <somecs...@gmail.com> wrote: > You'll notice that a different intent is fired when the calls ends. filter > for it and make it default as well. (use the log of course). > > On Mon, Jan 12, 2009 at 2:12 PM, shimo...@gmail.com <shimo...@gmail.com>wrote: > > > > > Hi, > > > Did that, and it seems to work, but - > > > Whenever the device is in the built-in dialer application, the intent > > is > > not fired when I press the CALL button, so I basically lose control > > over > > the button after every call (since the device auto-launches the built- > > in > > dialer after any call ends). > > > Anything I can do against this ? > > > While on this subject - I added the code to be notified on calls > > ending, > > wanting to have the device launch MY application instead of the built- > > in dialer > > when calls end. I was able to launch 3rd party apps when calls end, > > but not > > launch my own app. Any tips ? > > > TIA > > > On Jan 12, 2:43 pm, "Aryeh Tasher" <atas...@gmail.com> wrote: > > > add the CALL_BUTTON intent filter with category DEFAULT > > > > On Mon, Jan 12, 2009 at 7:11 AM, shimo...@gmail.com <shimo...@gmail.com > > >wrote: > > > > > Hi, > > > > > What ?! > > > > > I was told at these forums it can not be done for the PHONE button... > > > > > How ? > > > > Is it the same code as for the camera button ? > > > > What permissions are needed ? > > > > > If I can do this it would be a GREAT feature for my app ! > > > > > On Jan 12, 4:40 am, "Dianne Hackborn" <hack...@android.com> wrote: > > > > > I believe you can already do that. > > > > > > On Sun, Jan 11, 2009 at 1:23 AM, shimo...@gmail.com < > > shimo...@gmail.com > > > > >wrote: > > > > > > > Hi, > > > > > > > How about an option to assign pressing the PHONE button to launch > > my > > > > > > app ? > > > > > > (when there are no pending incoming calls) > > > > > > > TIA > > > > > > > On Jan 10, 2:35 am, "Dianne Hackborn" <hack...@android.com> wrote: > > > > > > > It would be nice to have a way to replace the incoming call > > screen or > > > > > > other > > > > > > > parts of the incoming call handling, but it is pretty non-trivial > > to > > > > do. > > > > > > I > > > > > > > am not aware of any current work going on to do this. You can > > have a > > > > > > look > > > > > > > at the source and see what is involved. > > > > > > > > On Fri, Jan 9, 2009 at 3:39 PM, Brad Fuller < > > > > bradallenful...@gmail.com > > > > > > >wrote: > > > > > > > > > Thanks Dianne, > > > > > > > > > Then perhaps there are ways to implement "partial" events for > > > > incoming > > > > > > > > calls. When an incoming call is detected, I imagine that there > > are > > > > > > > > several separate events. For example: get the number of the > > > > incoming > > > > > > > > call; see if it's in the contact list; display the onscreen > > graphic > > > > of > > > > > > > > an incoming with the phone number and the contact name, call > > the > > > > > > > > ringtone manager: etc. Then, when the phone is off-hook, > > display > > > > "Call > > > > > > > > in progess" text.. etc. > > > > > > > > > I assume that these are separate classes. So, could one display > > > > their > > > > > > > > own "incoming call" graphic? Or replace the RingTone manager > > (not > > > > the > > > > > > > > ringtone, like ExtendedRings does), etc? Or are they not > > separate > > > > > > > > classes or all private? > > > > > > > > > Does that make sense? > > > > > > > > > On Fri, Jan 9, 2009 at 2:56 PM, Dianne Hackborn < > > > > hack...@android.com> > > > > > > > > wrote: > > > > > > > > > Currently you can intercept outgoing calls and replace that > > with > > > > your > > > > > > own > > > > > > > > > behavior, but we don't yet have a way to intercept incoming > > > > calls. > > > > > > > > > > The issue of built-in apps using internal APIs is kind-of a > > > > > > red-herring. > > > > > > > > > Yes, in the case of the phone UI, there are a bunch of APIs > > that > > > > you > > > > > > need > > > > > > > > to > > > > > > > > > be able to implement something like your own in-call > > screen... > > > > > > however > > > > > > > > the > > > > > > > > > fact that they are internal is not really the issue: we could > > > > expose > > > > > > > > them, > > > > > > > > > but it still wouldn't work because the current implementation > > of > > > > them > > > > > > > > > requires that you actually be running in the same process as > > the > > > > > > > > telephony > > > > > > > > > subsystem, so they just can't be used by other apps. For the > > > > most > > > > > > part, > > > > > > > > we > > > > > > > > > make APIs private because they are not yet something we can > > > > maintain > > > > > > in > > > > > > > > the > > > > > > > > > future platform are even able to be used successfully by > > > > > > applications. > > > > > > > > Not > > > > > > > > > out of some malicious goal to make sure nobody else can make > > > > their > > > > > > own > > > > > > > > > whatever UI. > > > > > > > > > > Outside of the phone system, for the most part the platform > > > > > > applications > > > > > > > > use > > > > > > > > > private APIs because we didn't have time to clean all of the > > apps > > > > up > > > > > > as > > > > > > > > we > > > > > > > > > were evolving the official SDK into something that we could > > > > support > > > > > > in > > > > > > > > the > > > > > > > > > long term. We would love to accept patches that fix these > > APIs > > > > to > > > > > > switch > > > > > > > > to > > > > > > > > > the public APIs. > > > > > > > > > > On Fri, Jan 9, 2009 at 1:07 PM, Brad Fuller < > > > > > > bradallenful...@gmail.com> > > > > > > > > > wrote: > > > > > > > > > >> On Fri, Jan 9, 2009 at 1:02 PM, moazzamk < > > moazz...@gmail.com> > > > > > > wrote: > > > > > > > > > >> > I don't know what you mean by replace with your own code > > but > > > > you > > > > > > can > > > > > > > > >> > setup a receiver in your app which is called when a call > > is > > > > > > received. > > > > > > > > >> > I remember reading about it in the documentation (if I > > > > remember > > > > > > > > >> > correctly). > > > > > > > > > >> What I mean is that instead of the default process that > > happens > > > > when > > > > > > > > >> an incoming call is detected, another process is called. > > > > > > > > > -- > > > > > > > > Brad Fuller > > > > > > > > -- > > > > > > > Dianne Hackborn > > > > > > > Android framework engineer > > > > > > > hack...@android.com > > > > > > > > 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 > > > > > hack...@android.com > > > > > > 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 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 -~----------~----~----~----~------~----~------~--~---
