That I'm not sure about. It should have asked you again, especially after re-installing. I know this because I've made an app that replaces the default call log as well, and every time i re-install (debug or release), I have to re-select my default.
A similar issue I did know about, though, is if you would have selected the original Dialer app as your default, you would have run into the same problem as you are now. I've been wondering how to fix this. If anybody has a solution, please help. Thank you. On Tue, Jan 13, 2009 at 9:07 AM, shimo...@gmail.com <shimo...@gmail.com>wrote: > > Hi, > > One more issue - everything was working fine on my ADP1 device. > I selected my app (TAKEphONE) to be the default handler for > this, so every time I pressed the CALL button my app launched by > default. > > Then I wanted to check something, so I went to the system settings, > to the "Applications" section, selected my app, and tapped the "clear > defaults" > button. > > BUT - now when I press the CALL button - I no longer see the dialog > asking me which app to launch (mine or the Dialer). > Tried removing my app and re-installing - it did not help, either. > > How can I restore things to the way they were ? > > 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 -~----------~----~----~----~------~----~------~--~---
