Sorry, if your issue is the user being able to decide between your application and another, then yes the current system design is very much around the idea is in control of the applications, not the other way around. Note that the use -can- specify when making that selection that the application is to be used as the default, so they won't be asked again. I can imagine, however, many ways you could get around this, so it's doubtful that you could make in app that covers all of the holes if that is what you want.
This really just isn't how the system is designed to work: our first priority is to protect the user from applications, not to protect applications from a certain user. If you are interested in these kind of multi-user scenarios, you could look at contributing patches to the open-source project to enable these features in future versions. I'm sorry we don't have a better answer for you than that. On Nov 16, 1:50 pm, Marc <[EMAIL PROTECTED]> wrote: > The prototypes I developed implement some tricky filters on things > like contacts, received and sent messages (sms, mms etc.) logs of > incoming / outoing calls. Strong encryption based on TriplsDES of any > communication data stored on the phone etc. The same filters (added > mainly as additional attributes to the contacts db) shall block > incoming calls or sms / mms messages when they're not desired > depending on the cirumstances, meeting, wife, kids etc. etc. > > If the user can chose between the "protected" application, or the > public one (which will still show all the contents without the > filters), then there is no point in the above. The main reason is to > fully protect information, and not only protect it if for instance > your wife choses to pick the right sms application.... > > Anyways, to do this I also need to be able to intercept incoming > events like messages, calls, and "on the fly" decide to hide them, or > divert them to my voicemail, (and hide the sms from the voice box for > the notification of a new voice-mail etc.) > > A lot of time and efforts went in the prototypes which are working in > an emulated version of the previous API. > > This was supposed to be a suite of "serious" enhancments for all major > base Android applications, that would make sense for many people I > know, who keep struggleing with muting phones when neccdesary, > deleteing sms messages, cleaning call logs etc. etc. - If you see what > I mean... > > All for the bin now... and I had put a lot of trust in Android for > making this possible. (Something not available today on any movile > phone you can buy, and I know there is a certain demand for this out > there...) > > Anyways, too bad for me I guess :-) > > Cheers, marc > > On 16 nov, 22:37, Romain Guy <[EMAIL PROTECTED]> wrote: > > > I am very sorry to hear you cannot do exactly what you want with the > > telephony features but it is still true that you can replace core > > apps. Like I explained in another thread, we removed APIs that we felt > > we would not be comfortable maintaining forever. I know it's annoying > > but it's better for everybody involved if we do it right. > > > We are definitely interested in hearing your feedback. Please file > > bugs to tell us what features are missing or what features you need to > > implement what you want. > > > On Sun, Nov 16, 2008 at 1:34 PM, Marc <[EMAIL PROTECTED]> wrote: > > > > That was true, until SDK 1.0, as many promises over the past months... > > > Where is provider.Telephony now? > > > I've spend weeks developing a working prototype based on announcements > > > and the previous version of the API. > > > Sorry mate, but all of this is becoming a joke, really... > > > Thanks for your answer. > > > Good luck with Android in the future, but I'm done with it. > > > Cheers, Marc > > > > On 16 nov, 22:09, Romain Guy <[EMAIL PROTECTED]> wrote: > > >> Hi, > > > >> You cannot replace them physically in the system partition. However, > > >> you can make your application respond to the same intents as the core > > >> apps (for instance, HOME for the Home app) and the user will then have > > >> the choice (with the option of which application to use by default) > > >> between the core app and your app. > > > >> There really is nothing special about this. Just proper use of intents > > >> and intent filters :) > > > >> On Sun, Nov 16, 2008 at 7:09 AM, Marc <[EMAIL PROTECTED]> wrote: > > > >> > Hi, > > > >> > Does anyone know for sure whether it is possible to replace the > > >> > default standard applications (under /system/app) with my own. There > > >> > have been quite some messages about this, but no concrete and simple > > >> > yes/no answer. (With a pointer to a concrete example or some "official > > >> > instructions". In the end, this is supposed to be ONE of the major > > >> > advantages of Android as announced. - full flexibility and all > > >> > applications are "equal"... > > > >> > I want to develop a commercial suite of standard applications, and if > > >> > I can't replace the original ones, then this does of course not make a > > >> > lot of sense. > > > >> > I'm not interested in a hack through a root access. I'm looking for > > >> > the clean and officially supported way of doing this (as advertised by > > >> > google and others over the monts) > > > >> > Cheers, Marc > > > >> -- > > >> Romain Guywww.curious-creature.org > > > -- > > Romain Guywww.curious-creature.org --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
