On Nov 17, 7:54 pm, String sterling.ud...@googlemail.com wrote:
On Nov 17, 7:43 pm, Dianne Hackborn hack...@android.com wrote:
I will probably make this API a no-op, since it violates the principle of
one app not being able to break another app
+1
Especially with the Running Services
On Nov 17, 4:05 pm, Dianne Hackborn hack...@android.com wrote:
2.0 includes a UI showing you which -services- are running and the resources
they are using. This is what you really care about
Don't you care just as much about Activities that have threads running
the background?
Two more
On Wed, Nov 18, 2009 at 8:27 AM, jotobjects jotobje...@gmail.com wrote:
Don't you care just as much about Activities that have threads running
the background?
No, the system can freely kill those processes when it needs memory. Thus
this isn't the cause of the main problem, the overall
On Nov 18, 9:53 am, Dianne Hackborn hack...@android.com wrote:
On Wed, Nov 18, 2009 at 8:27 AM, jotobjects jotobje...@gmail.com wrote:
Don't you care just as much about Activities that have threads running
the background?
No, the system can freely kill those processes when it needs memory.
On Wed, Nov 18, 2009 at 12:18 PM, jotobjects jotobje...@gmail.com wrote:
If the system is slow due to CPU contention then an Activity running
in the background would also be part of the problem. If the system is
low on memory the System can also kill Services. But I get it that
too many
On Wed, Nov 18, 2009 at 18:53, Dianne Hackborn hack...@android.com wrote:
I'm not sure which UI you are talking about. The force stop button that
has been around since 1.5 does everything we have been talking about:
killing processes, unregistering alarms, etc. The new running services UI
2009/11/18 Cédric Berger cedric.berge...@gmail.com
So now that (I think) I understand what this force stop is really
about (completely and definitely stopping an app) :
Are there situations where it is done by the system (automatically) ?
(ie. in case it is too low on memory).
Nope,
On Wed, Nov 18, 2009 at 22:45, Dianne Hackborn hack...@android.com wrote:
2009/11/18 Cédric Berger cedric.berge...@gmail.com
Are there situations where it is done by the system (automatically) ?
(ie. in case it is too low on memory).
Nope, definitely never ever. The user must explicitly
On Nov 18, 1:55 pm, Cédric Berger cedric.berge...@gmail.com wrote:
I meant not when the user requested it, but when the system went
really too low on memory : as I understand the system may eventually
have to kill some services (even if it is not a full force stop) ?
(And if not, what
I think it would be nice if the to-be-killed/restarted apps/services
get a chance to say what it is doing. It's normal apps/services
obligation to provide such information; it's task manager apps
obligation to collect them and present to users.
Or make it a system service (may be some dialogs) to
That's not the purpose of this API, which is to allow the user to force stop
an application right now, immediately, I don't care what the damn app wants.
:}
There is a UI in 2.0 for the user to explicitly stop any currently running
services.
On Tue, Nov 17, 2009 at 5:15 AM, Bo
On Oct 13, 8:09 pm, EboMike ebom...@gmail.com wrote:
Task killers aside, what about if the OS decides to stop a process
because memory is low? Say an app has an alarm set to happen in 2
hours, and the user decides to run Google Maps for a minute. Android
might kill said app because memory
On Tue, Nov 17, 2009 at 11:36 AM, jotobjects jotobje...@gmail.com wrote:
On Oct 15, 3:07 pm, Dianne Hackborn hack...@android.com wrote:
What these programs are doing is using the API that is tended to force
stop
-everything- about the application: stop all services, cancel all alarms,
On Tue, Nov 17, 2009 at 11:41 AM, jotobjects jotobje...@gmail.com wrote:
Use Jason's solution. Also if the system kills the Process the
system will later restart the Process if it had a Service running but
it is up to the service to reset its own state.
Not when using this API, which kills
On Oct 15, 3:07 pm, Dianne Hackborn hack...@android.com wrote:
What these programs are doing is using the API that is tended to force stop
-everything- about the application: stop all services, cancel all alarms,
remove all notifications, etc. This is all working as intended, the apps
are
On Fri, Oct 16, 2009 at 00:07, Dianne Hackborn hack...@android.com wrote:
If you kill the process, it will not impact the alarms, the same as it won't
impact notifications etc.
What these programs are doing is using the API that is tended to force stop
-everything- about the application: stop
2.0 includes a UI showing you which -services- are running and the resources
they are using. This is what you really care about, not whatever random
processes are being kept around by the system in case it needs them later.
(Fwiw, the worst that can happen is a bad app sits there spinning the CPU
Personally I would like to see this API go away. I'm finding we now
have to code around task killing applications, which shouldn't be the
case. Being a good Android citizen and following the rules, allowing
the OS to do the work it was designed to do is the way to go. Users
are confused when the
On Nov 17, 7:43 pm, Dianne Hackborn hack...@android.com wrote:
I will probably make this API a no-op, since it violates the principle of
one app not being able to break another app
+1
Especially with the Running Services UI in 2.0, I'd suggest this is
the best solution.
String
--
You
In fact if you can have more control in 2.0, this will just help to not have
all this task killers used so blindlessly by everyone.
So removing this API will be become less important. And this one still may
be usefull in some cases. Just have to be used more wisely.
thanks dianne for the
2009/11/17 Cédric Berger cedric.berge...@gmail.com
In fact if you can have more control in 2.0, this will just help to not
have all this task killers used so blindlessly by everyone.
Unfortunately I think that is unlikely -- I can't count the number of places
I have seen on the web suggesting
I know this thread is talking a lot about task management. I think
the original post was about making alarms that still occur even if the
app is closed. This is how I do it:
1) Use AlarmManager service to schedule PendingIntents in the future
(I.e. xx min from now)
2) Creat an
On Oct 15, 4:34 pm, Jason B. jason.ba...@gmail.com wrote:
Using that approach works great for my app. That way it doesn't
matter if my app ever gets killed. The alarm will trigger in the
future and the intent will restart my service
I believe the point of this thread is that Task Killer
When I use the method above. Even after I kill my app and service with
task manager my alarms still trigger. I believe its because the
AlarmManager service has been given a pending intent that will
relaunch my service which handles the alarms.
Both alarmmanager and the pending intent are
If you kill the process, it will not impact the alarms, the same as it won't
impact notifications etc.
What these programs are doing is using the API that is tended to force stop
-everything- about the application: stop all services, cancel all alarms,
remove all notifications, etc. This is all
:)
I am the taskiller developper.
If an user choose to kill your app. Your app may not be restarted.
Users are using taskiller because too more apps have bad implemention
of broadcasters.
Too many apps are launching without user action, like uninstalled
widgets, because they receive
Broadcast
On Oct 13, 4:50 pm, Nicolas Thibaut nthibau...@gmail.com wrote:
And the bad news is that others task managers are implementing
autokill or Boot killwhich can made many apps crashing (if
your app use an intents to another app...if this app is autokilled
your app will never worl :( ...
Maybe make another API call that allows killing the service,
notifications, and etc of an application except for alarms? I think
other applications are affected the most by their alarms getting
totally wiped out by another application.
Too many task killing applications are using this API call.
Hi Nicolas,
I'm using your app on my personal phone, but I kill apps from the Task
Bar widget, so I chose carefully which one I want to kill, but most
users are using the other widget which only displays the number of
apps running and kills all (except system apps and those on ignore
list) of
Task killers aside, what about if the OS decides to stop a process
because memory is low? Say an app has an alarm set to happen in 2
hours, and the user decides to run Google Maps for a minute. Android
might kill said app because memory runs low. Ten minutes later, the
user is back on the home
On Tue, Oct 13, 2009 at 9:09 PM, EboMike ebom...@gmail.com wrote:
Task killers aside, what about if the OS decides to stop a process
because memory is low?
It doesn't do what these apps are doing. As I said, what these apps are
doing (especially the ones that do this stuff behind the user's
That is intentional. Stopping an application is there for the user to stop
everything associated with it -- processes, alarms, services, notifications,
etc. They will not be restarted until someone explicitly does so (typically
this would be the user re-launching the app and having it do the
Thanks Dianne for the quick answer.
Actually TasKiller is not automatically killing apps, but it has a
widget that allows users to kill (almost) all apps with one click.
Most of the Android users that I know are using something similar to
TasKiller so this is a tricky problem, users will blame
*sigh* I knew I shouldn't have made that API public. :}
On Mon, Oct 12, 2009 at 4:09 PM, Lazarus 101 lazarus...@gmail.com wrote:
Thanks Dianne for the quick answer.
Actually TasKiller is not automatically killing apps, but it has a
widget that allows users to kill (almost) all apps with one
34 matches
Mail list logo
