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. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
