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).
-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. -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. 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. JBQ On Thu, Mar 26, 2009 at 6:58 AM, Streets Of Boston <[email protected]> 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 <[email protected]> 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 <[email protected]> >> wrote: >> > On Wed, Mar 25, 2009 at 11:02 PM, Romain Guy <[email protected]> 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 [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 -~----------~----~----~----~------~----~------~--~---
