Sorry about implying another sand-box. What I meant was migrating the concept of native-client and providing an equivalent "language", if you will, that isn't running through a VM. I guess I was trying suggest a environment similar to what is provided by dalvik minus the VM. But I understand and agree with what you are saying.
On Jan 7, 1:03 pm, "Dianne Hackborn" <hack...@android.com> wrote: > On Wed, Jan 7, 2009 at 10:00 AM, Quartz <william.qua...@gmail.com> wrote: > > currently supported and I am sure ARM would be, eventually, but it > > would seem to me that having a sand-boxed native code environment > > would be beneficial too. > > Android already does native sandboxing, as described in the security model > doc. That is why I say it would have no purpose for android applications > (though it may be useful for its intended purpose in the browser). > > > I understand the kernel is currently > > providing sand-boxing, but the only code you can write is dalvik, at > > least from the SDK perspective. I was thinking it would be nice to be > > able to code in C or assembly--even if it is a subset--in a sand-boxed > > fashion. > > Adding another sandbox that does the same thing as the existing Android app > sandbox is not going to help here. :) > > -- > 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 -~----------~----~----~----~------~----~------~--~---
