Google has certainly posted "we're working on it" type hints on *many* issues / upcoming features. Dates no, but it would be good to know if this is being looked at.
I certainly disagree that this does not belong in Android. Here a few reasons why (minimized): - There is a huge demand for "Parental Control" type management on Android. Many parents buy Android devices for their young children and teenagers and wish for some control and visibility vs "letting them loose" with the device. The company I work for has sold many devices pre-bundled with this functionality and I know from experience that many people simply will not buy an Android device (or any other ecosystem) that does not support/have this functionality. - Take a look at the hundreds (more?) of "App Lock" and "Parental Control" type applications that currently exist on Android right now. All of these applications are in high demand and all of them are currently using hacks of various sorts for implementation. Many even requiring rooting the device. - Android is already fragmented. What works on one device may not work on another. I'm fine with that personally and love the diversity. However, the general API set you can mostly rely on. Having each vendor create an API for this kind of functionality would be an absolute nightmare. - In general, yes, applications should absolutely be sandboxed. And I actually agree with the removal of READ_LOGS from a security standpoint due to the amount of data most applications dump into logcat -- who knows what goodies I could scrape from there. However, there should be exceptions to the "control" portion of this rule as long as the user / device admin authorizes it. As far as it being hard to maintain, I'm not seeing it. Start out with a few simplistic hooks for the common cases and go from there. Some of the hooks (e.g. IActivityWatcher or IProcessObserver) are/were already semi-present in the system as non-public and locked down APIs. What's needed is a good system for allowing device administrators to allow certain applications to use similar API sets. I think at this point I may develop some customization's to Android myself, submit them, and hope for the best. I'm confident this can be implemented in a secure & user friendly manor. What I don't want it to waste my time if someone at Google is already doing it. On Thursday, July 26, 2012 5:51:02 PM UTC-6, Kristopher Micinski wrote: > > I honestly don't see what you expect to be said. > > The Android team has never released their plans for APIs until they > are actually stable. It's sort of risky to promise things that might > not materialize. While I agree this sort of functionality is useful, > I personally do *not* believe it belongs in Android. > > I do believe, however, that it belongs in vendor specific mods, that > have custom apps. > > Why? Because vanilla Android shouldn't be tasked with these kinds of > extensions (personal opinion, mostly..). > > It's hard to design these kinds of things, because for many people > this might be considered bloatware. I agree that it's a useful > feature, no doubt, but I believe that it doesn't believe at the app > level (no app should be able to modify the system behavior, seems to > be an Android maxim at this point!), and not in the vanilla system > either. > > This seems like something that has a lot of design decisions > associated with it, and for Google to maintain it would be very hectic > logistically. I suspect that it's not completely implausible that > this will eventually appear in vanilla Android, but I find it somewhat > unlikely, just based off of the kinds of decisions I've seen made in > the platform to date. > > 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
