On Mon, Apr 20, 2009 at 1:07 PM, Hans <[email protected]> wrote: > On Apr 20, 1:02 pm, Dianne Hackborn <[email protected]> wrote: > > The data roaming thing is fixed in Cupcake. > Fixed? It's not broken as far as I can tell. It's a System setting. > Seriously, why on earth would you change it? I'm sure that no > developer has requested this as a change, so why is it changing?
Yes, fixed as far as applications can no longer modify it without the user being involved. This wasn't done for application developers, it was done for users. > > If you are doing this for a vendor, you can have your app signed with the > > platform certificate for the vendor, and do many of these things. What > you > > are asking is not within the scope of the third party SDK, and is most > > likely something we don't want to have within it. > Apologies, but I don't understand how having my 'app signed' for a > vendor will suddenly make new features of the SDK available. Does > doing this get me a different Android Jar that suddenly makes the Sync > Manager available? It won't make any new kind of SDK available, but you can do this if you are being bundled in the system image of a particular device (as you seemed to imply by saying you are writing something for a vendor), in which case you can be signed by them to use system permissions and use their internal APIs. This would never be something you could put up on Market (nor would such a thing really work). > Why wouldn't you want to be let applications control the functionality > of the phone? Protecting the user? That can't be it because you can > stomp all over the SDCARD, you can run background services that run at > boot, you can upload data from the phone to pretty much any website > you wish. The main reasons are either because it is considered to be too insecure (such as installing applications without going through the installer UI), or because it is an API that an engineer doesn't want to commit to supporting forever (such as telephony stuff, which is especially fragile with CDMA support going in). I am hoping that in an upcoming release we will close the issue with the SDCARD not requiring a permission. i don't really see what the security issue is with starting background services. I would also like to close any holes for applications to send data over the network without explicitly requesting it, but am not sure what or when we might do that. Our goal should very much be to close holes as we find them, which you already see happening in Cupcake, not just give up and let applications do whatever they want. Where is this mysterious group who decides what's dangerous and what > isn't, when it's all technically dangerous to begin with...? If you are coming at the position that security isn't useful because everything an application can do is dangerous, then I'm not sure what kind of useful discussion we can have. :} Anyway, the security engineers, core technical team, and engineers responsible for their area of the system makes these kinds of decisions. -- 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, and so won't reply to such e-mails. 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 -~----------~----~----~----~------~----~------~--~---
