On Fri, Jul 27, 2012 at 3:26 PM, Bryan Ashby <nuskoo...@gmail.com> wrote: > Glad to see a response, thanks. > > While I think a platform feature vs an API set developers can access is > better than nothing, it's also much too restrictive. What I mean by this is > that parents and admins want to buy the devices they want to buy -- and > still have the ability to "lock them down". This goes for the consumer and > enterprise world: > > Consumers want the latest cool gadgets and/or the budget gadgets -- And they > want parental controls on them. > Many enterprise users are now allowing BYOD policies as long as certain > software is installed on them (e.g. for DLP, etc.) > Filtering solutions are very much like anti-virus & anti-malware solutions: > People have the one they trust; they don't want any others. >
I still think all of this fits in the category of "apps that can change system behavior," which doesn't fit into the current vision I have of the Android platform. (And, apparently, this view is shared by most others, given Google's philisophy and track record of restricting APIs that allow such things..) > Forcing buyers to stick with devices that have enabled parental control > features for example is highly limiting, and I think, a mistake. > That have enabled them? Why would they ever be enabled by default? I think that at the current time the quick fix is for vendors to have specific apps integrated into their firmware (say, for example, your app, with a system signature or otherwise integrated into the platform), and then have vendors market their devices as being "safe for kids." This is certainly a feature of Android that vendors do by default now (looking at recent ads for custom firmware extensions..) > Perhaps another solution is a API set and a new level of permission > authentication. E.g., an developer would need to sign with a key that > contains a trusted CA (Google stamp of approval or such) > Yes, that is one possible road for a system extension capability. I would also be interested in such a utility. However, a mere CA type signature probably won't really work (we've all seen CAs fall in the past, and while it helps, it might not be enough from a really mission criticial standpoint). I think one thing that may help is custom android "extensions" whose security implications can be verified and enforced at runtime may be an option, but I'm not sure of this. kris -- 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
