It is not currently possible to replace tabs across non-trusting .apks -- this would require running the activity of the tab content in a different process than the containing tab, and we just can't do that right now.
Also there is nothing in the SDK saying that Dialtacts as it stands will continue to exist in its current form. I would completely expect that other manufacturers of Android phones will have their own totally different dialers, with different tabs, or no tabs at all, so replacing the entire UI is really the only safe thing to do. As far as permissions, I believe the only special permission Dialtacts has is for placing emergency calls, so if you wanted to replace it you would need to have a button to get to the built-in dialer for emergency calls. Sorry about that, but that's unfortunately a restriction we have to live with for now. I think there may also be some private APIs that the current impl uses (such as maybe showing presence information with contacts) so you wouldn't be able to write something that is functionality identical to the standard one. This is also somewhat the nature of the beast -- you can be sure that various manufacturers will do exended dialers with all kinds of hooks into special parts of their particular device. This is really a UI that is so fundamental to a lot of the specifics of a particular device that these things are going to be the case. We would certainly like to have more extensive facilities for replacing/customizing the dialer, but I can't tell you what or when that might be. If there are things you see that can help, we would welcome patches. On Thu, Mar 5, 2009 at 1:14 PM, MakeMobile <makemobileinnovati...@gmail.com>wrote: > > What do you mean by not supported? Do you mean that you should not be > able to do this > for any TabActivity class? What is to stop other developers from > falling into the > same trap? > > Also, if this is the case, it seems to be impossible to create a new > call-log > application because one would have to re-implement the entire phone > application, > which would be Ok if that were possible. But, looking at the code it > seems that the > phone application has access to privileged code, making writing a 3rd > party phone app > imposible. So it is impossible to completely replace the default phone > application? > > > > On Mar 5, 3:13 pm, Dianne Hackborn <hack...@android.com> wrote: > > Ah yeah. This is either a bug, or just not something that is supported. > We > > will change Dialtacs to not use implicit intents for its tabs, since > > replacing them just won't work. This will avoid running into such > problems > > involving it. > > > > > > > > On Thu, Mar 5, 2009 at 8:53 AM, DanM <dan.me...@gmail.com> wrote: > > > > > I'd also like to point out that there is a bug in the android system > > > when handling intents for subactivities. > > > > > I created an application that responds to the same intent as the call- > > > log portion of the phone application (the intent that is started when > > > the call-log tab is selected within that app). Normally, the activity > > > that is started via this intent runs inside the call-log tab of the > > > phone application, but if the activity resolver runs, the activity > > > started thereafter runs as a regular full-screen activity and not > > > inside of the call-log tab of the phone application. This happens no > > > matter which activity you choose to start with the resolver, even if > > > you select the default activity that usually runs with the phone > > > application. It seems to me this has to be a problem with the activity > > > resolver. > > > > > The problem with SET_PREFERRED_APPLICATIONS may be related to this. It > > > happens if you select the "use by default for this action" check box, > > > and then select one of the activities. The application then crashes > > > with the error above. > > > > > -Dan > > > > > On Mar 3, 11:38 am, MakeMobile <makemobileinnovati...@gmail.com> > > > wrote: > > > > Hello, > > > > I'd like to revisit a topic that was previously posted, but never > > > > resolved. > > > > > > > http://groups.google.com/group/android-developers/browse_thread/threa... > > > > > > "Neither user 10002 nor current process has > > > > android.permission.SET_PREFERRED_APPLICATIONS" > > > > > > I'm running into the same problem as the original poster. Currently > my > > > > development is blocked until this problem is resolved. What is > causing > > > > this problem and how do I resolve it? If you need more information > > > > about the application I'm writing, I'm happy to provide it. > > > > -- > > 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 -~----------~----~----~----~------~----~------~--~---
