On Thu, Mar 26, 2009 at 4:14 PM, Jean-Baptiste Queru <j...@android.com> wrote: > > There are some problems with that approach: > > -it's an arms race. You've already identified the need for certain > apps to continue running even when there's an "exclusive" app running, > which'd have to be protected by a permission. Either that permission > is system-only and we move further away from the goal of having all > applications equal, and it's accessible to all applications and it's > only a matter of time before all applications have it, which makes the > entire exercise pointless (put yourselves in the shoes of the > developer of an app with background components - from their point of > view, their app is obviously the most important app, and they don't > want anyone to be able to tell them that their app isn't allowed to > run).
Screw the developer. I'll put myself in the shoes of the user. I have launched myself a game. I want it to run at full speed. I could care less that a background service, polling RSS feeds have just found out that someone posted a new blog entry. I'm sure you now understand there's no issue with background apps and which is more important. > > -the granularity that you really want is not that of an application - > preventing other applications from running will prevent their services > and providers from running even if they are necessary to run the front > application. Now, I realize that this permission should not be that simple - it should allow the apps to specify which components are OK to run (system components will always run, of course). For example, the RSS reader application will want to run itself, and this or that service it depends on. I don't see how this would be a problem. The permission should simply allow one or more components to be listed as dependencies. > > -even if you could do that, it would only be a partial solution at > best, as system_server itself will probably still do a few > allocations, and binder transactions eventually cause GCs as well. Processes, which absolutely need to run (performing or not GCs) is OK to run. Think about it - the experience will in *any* case be greater, than it is now. > FWIW, this would be an excellent discussion for the android-framework > group, where we discuss how changes in the android platform impact > SDK-level application development. I agree, but since this originated from a android-developers post I thought it's OK to discuss here. Will move the discussion there this weekend, when I have the time to think about this feature a bit more. Cheers > > JBQ > > On Thu, Mar 26, 2009 at 6:58 AM, Streets Of Boston > <flyingdutc...@gmail.com> wrote: >> >> Add my vote for this option/feature: A permission for an app to become >> the only app running (except maybe the phone-app and incoming SMS, >> etc). >> >> On Mar 26, 7:26 am, Stoyan Damov <stoyan.da...@gmail.com> wrote: >>> I've also proposed a solution to this - adding a permission for apps >>> to request that they run alone, uninterrupted by other processes. >>> >>> That is, the app can request a permission, demanding that the app can >>> only be interrupted by an external event, such as phone call, all >>> other services and background processes (other than the ones the OS >>> can't go without) are paused when app is running. >>> >>> I know it's quite tricky to implement this, because, for example, when >>> an SMS is received it needs to be stored in the database, and this >>> will require some memory, which will need to be discarded, when the >>> SMS is written to the database, and this will trigger GC. However, >>> when such a message is received, and the OS knows that an app with the >>> special permission runs in the foreground, it could delay the GC >>> either until: >>> >>> - the app itself allocates memory (no matter if it might not be >>> actually GC'ed until the app finishes) OR >>> - the systems goes pretty low on memory >>> >>> At least, non-stock services (i.e. services, developed by 3rd parties) >>> can be suspended during the lifetime of an application requesting the >>> special permission. >>> >>> Cheers >>> >>> >>> >>> On Thu, Mar 26, 2009 at 11:51 AM, Stoyan Damov <stoyan.da...@gmail.com> >>> wrote: >>> > On Wed, Mar 25, 2009 at 11:02 PM, Romain Guy <romain...@google.com> wrote: >>> >>> >> The trick is simple: avoid any allocation that might trigger a GC. >>> >>> > It's not that simple at all. >>> > In fact, it is *impossible* on Android, or any other mobile OS which >>> > allows background processes. >>> >>> > I've already said this once -- even though your game can be tuned to >>> > the max, nothing prevents *other* apps from triggering GC. >>> > That is, in my game, I *never*, *ever* do any allocation after startup. >>> > However, other background processes do trigger GC, and voila - my game >>> > stutters for a bit when GC kicks in. >>> >>> > Compare to iPhone, which disallows background processing and the >>> > foreground app is never interrupted. >>> >>> > Cheers- Hide quoted text - >>> >>> - Show quoted text - >> > >> > > > > -- > Jean-Baptiste M. "JBQ" Queru > Android Engineer, Google. > > Questions sent directly to me that have no reason for being private > will likely get ignored or forwarded to a public forum with no further > warning. > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
