Hi Jarman, your project is in part very interesting for me. Could you tell me how you handle incoming calls? I'm interesting about accept or reject a call in my own app.
On 4 nov, 23:24, Jarman <[email protected]> wrote: > Sorry, I meant "she" of course, too fast on the keyboard :) > > This has been resolved, it´s not a bug. This is the response I got > when i reported it as a possible security issue: > > It depends on what you mean by "override the in-callscreen". > > In the discussion groups this *usually* comes up when someone wants to > totally replace the in-callUI with a new design (which should still > be > fully functional, but just look different.) This unfortunately isn't > possible in Android 1.x or 2.0 because 3rd party apps aren't (yet) > allowed > full access to the telephony APIs. > > But you're just talking about the ability to pop up some other > activity on > top of the in-callUI. Looking at your app's description, I assume it > listens forincomingcallevents, and then eventually launches some > other > activity on top of the in-callscreen. Sure, there's nothing > preventing > this; any 3rd party app (with appropriate permissions) can launch new > activities whenever it wants. > > (You're right that a malicious app could do this and be extremely > annoying, but the user can always hit HOME, and get back to the real > InCallScreen by pressing the green button or selecting the in-call > notification.) > > Also FWIW, this app (and the similar ones also in the market) do > require > at least a couple of permissions marked as "dangerous", so at least > the > user will see a warning before installing it... > > Bottom line: no security hole here. It's possible for an app (with > the > right permissions) to be annoying, but even so it's still fairly easy > for > the user to recover. > > On 4 Nov, 20:15, Disconnect <[email protected]> wrote: > > > Didn't the whitepages app come out in the very very first days of the > > market with this capability? (I didn't use it much, at the time there > > was no 3g in this area. Plus, submittingincomingphone #s to a 3rd > > party service was really skeevy.) > > > As an aside, Dianne is a girl's name. :) > > > On Wed, Nov 4, 2009 at 10:47 AM,Jarman<[email protected]> wrote: > > > I just had a private mail-discussion with Dianne Hackborn and he asked > > > me to put this issue on the Developer forum for further discussion. > > > > I have managed to override the in-callscreen from the Java API (i.e. > > > not modifying the source). > > > (If you want to se it happen, download Jarmans ReverseLookup from the > > > Market, it´s free) > > > > Reply from Dianne: > > >>> It can't be done in a supportable way without modifying the source. I > > >>> don't know how you went about your > > >>> solution, but there is probably a good chance that it would be broken > > >>> in a future version of the platform. Actually >> there could even be a > > >>> chance of it bring deliberately broken if security concerns get raised > > >>> (disrupting the > > >>> standard in-callinformation like this without the user approving is > > >>> something that is likely to get filed as a > > >>> security bug in the platform). > > > > What do think about this? > > > > Best Regards > > >Jarman > > > > -- > > > 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 -- 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
