Neither user nor current process has android.permission.SET_PREFERRED_APPLICATIONS

by Dianne Hackborn » Fri, 06 Mar 2009 04:13:38 GMT

Sponsored Links
 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.

> > 

Neither user nor current process has android.permission.SET_PREFERRED_APPLICATIONS

by Dianne Hackborn » Fri, 06 Mar 2009 07:54:28 GMT

 t 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

On Thu, Mar 5, 2009 at 1:14 PM, MakeMobile

Dianne Hackborn
Android framework engineer

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.


Sponsored Links

Other Threads

1. RERUN e-lifestyle MetroTV ttg programmer Gadget HARI INIpk. 11.05 WIB

Lagi ngantor kang ... :p
Sent from my BlackBerrypowered by Sinyal Kuat INDOSAT

-----Original Message-----
From: "Onno W. Purbo" <>
Date: Mon, 24 Jan 2011 07:16:21 
To: <>
Subject: [id-android] RERUN e-lifestyle MetroTV ttg programmer Gadget HARI INI
 pk. 11.05 WIB

RERUN e-lifestyle MetroTV ttg programmer Gadget
HARI INI senin 24/01/2011 pk. 11.05 WIB
isinya ANDROID vs BB :)))



2. Exceptions in user libraries

Hi there,

I am developing for Android from Eclipse running on the Windows OS. As
I have multiple projects that share certain parts of code, I have made
said code into an Android library, and then reference said libraries
to the projects. I am doing this by using the 'Library' panel under
the 'Android' section (when you right click -> Properties on a
project). The library projects have 'Is Library' ticked, and the main
projects add the library projects.

In terms of being able to build and run, this appears to work. However
I have run into two problems, one more serious than the other:

1. When I make a change to the source for a library, when I ask
Eclipse to run/debug it doesn't pick up the change. I have to instead
refresh (F5) the main project - this appears to correctly pull in
dependencies (incidentally, I also have to do this if I make a change
to native code using the NDK and rebuild the resulting .so file). Is
there a way to force these sorts of dependency checks to automatically
be taken into consideration when I debug run? I have got reasonably
used to refreshing when running, but it is somewhat easy to loose
track of what source file you are editing, and forgetting it is one in
a library that means a refresh is required. It can result in wasted
debug sessions when you are running unexpected code!

2. My more serious problem is: when an unhandled exception is thrown
in library code, it doesn't tell me about the exception in an easy
way. For example, today I had an exception raised, and it reported to
me that it was coming from the method, from - so I went through the various hoops for getting
the source code for Android onto my PC, so I could view, and saw the exception was coming from
'guardedRun', which in turn was calling 'onDrawFrame', which in turn
called out to my native render + update function (using the NDK),
which in turn called back into my Java code to load some music, and
*that* code then went onto attempt to access an array with an invalid
index. None of this was shown in the callstack (only
appeared there), instead I had to make my own version of GLSurfaceView
that had some try/catch statements that caught the exception, and gave
me a callstack of where the problem lies by using e.printStackTrace().
Once I had the callstack, I was able to fix up the offending code. I
don't remember having this problem before I made my code into a
library - I thought previously exceptions were getting caught much
earlier on. I am simply not remembering correctly? Or is there some
limitation when using libraries? If I am not remembering correctly,
clearly I just need to wrap my Java code that is being called from my
native code with try/catch/print exception blocks so I can avoid this
problem again.

I look forward to your responses,



3. samsung tab

4. custom widgets in animation

5. RERUN e-lifestyle MetroTV ttg programmer Gadget HARI INI pk. 11.05 WIB

6. [WTAsk] soal rooting HH.

7. WTNgelamun : Gadget Impian