Will it have a solution for wrongly close the background process?

3 views
Skip to first unread message

Billy Cui

unread,
Nov 23, 2009, 11:46:45 PM11/23/09
to android-platform
Android have a feature that can close any background process without
any warning, this will make it have enough ram available for
foreground apps, but will sure harm the background process, indeed, it
will have some chance to harm the foreground app, and make them
unstable or buggy.

For example:
http://code.google.com/p/cyanogenmod/issues/detail?id=647
and
http://groups.google.com/group/android-developers/browse_thread/thread/a276e8af22e3c2e4

I think these problem was caused by android kill the contactsprovider
and make the app unstable.

If the programmer don't know his app or background process when and
how will be killed, and he can do nothing for this, that's terrible
for programmers.

In most common app maybe not so important, their crash may only make
us unhappy, but if the apps like Phone were crash, we can not use it
as our mobile phone.

So, is there a clue for this? Or will have a solution to avoid this?

lbcoder

unread,
Nov 24, 2009, 10:46:56 AM11/24/09
to android-platform
This is a necessary feature that is actually very well implemented.
Specifically, it doesn't just go around killing things randomly, there
is a PRIORITY to what it kills, and some things it will NOT kill (i.e.
those required for the phone to operate). And no, it doesn't kill the
foreground process, so the effect on a particular program are
negligible -- the process that was killed will restart any time you
want it to, and if it was implemented well, it will have saved its
state and resume from right where it was when it was killed.

Also, your assumption that the programmer can't do anything about it
when their app is terminated is incorrect. When a process loses focus,
certain routines are immediately run, which, if written well, will
allow the process to prepare for the possibility of being terminated,
specifically, onPause(). You might want to read this
http://developer.android.com/guide/topics/fundamentals.html

And I don't see any connection between killing unnecessary processes
and those two links you provided. Seems to me like a wild and
unfounded assumption on your part based mostly on a lack of
understanding of the fundamentals of the platform.

On Nov 23, 11:46 pm, Billy Cui <billy...@gmail.com> wrote:
> Android have a feature that can close any background process without
> any warning, this will make it have enough ram available for
> foreground apps, but will sure harm the background process, indeed, it
> will have some chance to harm the foreground app, and make them
> unstable or buggy.
>
> For example:http://code.google.com/p/cyanogenmod/issues/detail?id=647
> andhttp://groups.google.com/group/android-developers/browse_thread/threa...

Billy Cui

unread,
Nov 24, 2009, 11:22:23 AM11/24/09
to android-platform
Sure I know the principle for killing the process, the point is too
many times our running background service was killed. I know it can
be restarted by our programming, but you will lost many information
you current run and will sure takes more cpu time and battery for
restart it.

As for the PRIORITY, as my known, there is no such priority you can
set in programming. Also, I know the foreground app won't be killed,
and I never said so, I said, IT HAS SOME CHANGE TO HARM THEM, not kill
them. So I take the problem with Phone app as example, Phone app was
harmed because of the background ContactsProvider was killed.

Or you can say that's because of bad programming, if so, could you
tell me how to fix it with good programming? I will happily take my
questions back:)


On Nov 24, 11:46 pm, lbcoder <lbco...@gmail.com> wrote:
> This is a necessary feature that is actually very well implemented.
> Specifically, it doesn't just go around killing things randomly, there
> is a PRIORITY to what it kills, and some things it will NOT kill (i.e.
> those required for the phone to operate). And no, it doesn't kill the
> foreground process, so the effect on a particular program are
> negligible -- the process that was killed will restart any time you
> want it to, and if it was implemented well, it will have saved its
> state and resume from right where it was when it was killed.
>
> Also, your assumption that the programmer can't do anything about it
> when their app is terminated is incorrect. When a process loses focus,
> certain routines are immediately run, which, if written well, will
> allow the process to prepare for the possibility of being terminated,
> specifically, onPause(). You might want to read thishttp://developer.android.com/guide/topics/fundamentals.html

Jean-Baptiste Queru

unread,
Nov 24, 2009, 11:29:16 AM11/24/09
to android-...@googlegroups.com
What are you trying to contribute here?

JBQ
> --
>
> You received this message because you are subscribed to the Google Groups "android-platform" group.
> To post to this group, send email to android-...@googlegroups.com.
> To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.
>
>
>



--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, 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.

Dianne Hackborn

unread,
Nov 24, 2009, 1:20:44 PM11/24/09
to android-...@googlegroups.com
On Tue, Nov 24, 2009 at 8:22 AM, Billy Cui <bill...@gmail.com> wrote:
Sure I know the principle for killing the process, the point is too
many times our running background service was killed.  I know it can
be restarted by our programming, but you will lost many information
you current run and will sure takes more cpu time and battery for
restart it.

If your service is being killed, it is simply because there is not enough memory to keep everything running that has been requested.  The issue is not with the background killing mechanism, but with there not being enough RAM for everything that is asking to run.

Also, since both of these bugs are explicitly about the cyanogen mod, it is not something we will spend investigating; that only makes sense if they are reproducible on a standard platform.

Heck, the bugs don't even say which -version- of the platform they are running.  And if it is 2.0, then what is being run is (a) not a final release, and (b) not yet optimized to run on lower-end devices like the G1.

As for the PRIORITY, as my known, there is no such priority you can
set in programming.  Also, I know the foreground app won't be killed,
and I never said so, I said, IT HAS SOME CHANGE TO HARM THEM, not kill
them.  So I take the problem with Phone app as example, Phone app was
harmed because of the background ContactsProvider was killed.

Phone app was harmed because it had a null pointer exception it wasn't handling.
 
Or you can say that's because of bad programming, if so, could you
tell me how to fix it with good programming?  I will happily take my
questions back:)

As JBQ says, what are you trying to contribute here?  This list is for contributing to the platform.

--
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

Billy Cui

unread,
Nov 24, 2009, 10:00:58 PM11/24/09
to android-platform
Thank you for your prompt reply.


On Nov 25, 2:20 am, Dianne Hackborn <hack...@android.com> wrote:
> On Tue, Nov 24, 2009 at 8:22 AM, Billy Cui <billy...@gmail.com> wrote:
> > Sure I know the principle for killing the process, the point is too
> > many times our running background service was killed.  I know it can
> > be restarted by our programming, but you will lost many information
> > you current run and will sure takes more cpu time and battery for
> > restart it.
>
> If your service is being killed, it is simply because there is not enough
> memory to keep everything running that has been requested.  The issue is not
> with the background killing mechanism, but with there not being enough RAM
> for everything that is asking to run.
>
> Also, since both of these bugs are explicitly about the cyanogen mod, it is
> not something we will spend investigating; that only makes sense if they are
> reproducible on a standard platform.
>
> Heck, the bugs don't even say which -version- of the platform they are
> running.  And if it is 2.0, then what is being run is (a) not a final
> release, and (b) not yet optimized to run on lower-end devices like the G1.
>
That sounds reasonable, maybe only cyanogen mod have such bug because
of his tweak. Then I will just keep on watching it.

> As for the PRIORITY, as my known, there is no such priority you can
>
> > set in programming.  Also, I know the foreground app won't be killed,
> > and I never said so, I said, IT HAS SOME CHANGE TO HARM THEM, not kill
> > them.  So I take the problem with Phone app as example, Phone app was
> > harmed because of the background ContactsProvider was killed.
>
> Phone app was harmed because it had a null pointer exception it wasn't
> handling.
>
NPE should harm the Phone app, but if the ContactsProvider was not
killed, there should no such NPE, am I right?

> > Or you can say that's because of bad programming, if so, could you
> > tell me how to fix it with good programming?  I will happily take my
> > questions back:)
>
> As JBQ says, what are you trying to contribute here?  This list is for
> contributing to the platform.
Sorry, I maybe wrong, problem about the background killing mechanism
should post in other group?

I just want to find a way for the developers can keep their background
process away from been killed, maybe use a special signal, of course
it should require special permission for this mechanism.

If it's not belong to this group, I say sorry to everyone in the
group :)

>
> --
> Dianne Hackborn
> Android framework engineer
> hack...@android.com
Reply all
Reply to author
Forward
0 new messages