Hi, I think it's a bug maybe.
Anyway - found a workaround - create a "stub" application (like "Hello world") and add to it's manifest file all the same intent-filters you want for the "real" app. Install it, make sure you see the "select default" popup for each intent, and now you can uninstall the 'stub' app. Now the "real" app should show in the "Select handler" popup, too. On Jan 13, 4:35 pm, "A T" <[email protected]> wrote: > 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, [email protected] <[email protected]>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" <[email protected]> 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, [email protected] <[email protected] > > >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" <[email protected]> wrote: > > > > > add the CALL_BUTTON intent filter with category DEFAULT > > > > > > On Mon, Jan 12, 2009 at 7:11 AM, [email protected] < > > [email protected] > > > > >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" <[email protected]> wrote: > > > > > > > I believe you can already do that. > > > > > > > > On Sun, Jan 11, 2009 at 1:23 AM, [email protected] < > > > > [email protected] > > > > > > >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" <[email protected]> > > 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 < > > > > > > [email protected] > > > > > > > > >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 < > > > > > > [email protected]> > > > > > > > > > > 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 < > > > > > > > > [email protected]> > > > > > > > > > > > wrote: > > > > > > > > > > > >> On Fri, Jan 9, 2009 at 1:02 PM, moazzamk < > > > > [email protected]> > > > > > > > > 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 > > > > > > > > > [email protected] > > > > > > > > > > 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 > > > > > > > [email protected] > > > > > > > > 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 [email protected] 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 -~----------~----~----~----~------~----~------~--~---
