[android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2017-08-04 Thread eslam elhoseiny
Did you find any solution ?

On Friday, September 23, 2016 at 2:44:34 PM UTC+2, Connexun India wrote:
>
> Hello,
>
> Can any buddy help to resolve the issue when app kill from background (by 
> swipe from recent) then i am not getting any location update? This is the 
> problem i am facing in Kitkat and Lollipop version of android.
>
> I am using GoogleApiClient for location update. Also i am using in service 
> for get the location.
>
> Thanks,
>
> Ajay
>
> On Friday, December 13, 2013 at 2:50:34 AM UTC+5:30, 3c wrote:
>>
>> The swipe app out of recent tasks is supposed (as far as I understand it) 
>> to terminate all activities but keep services running. This is true (and I 
>> verified that behavior) until KitKat (verified on 4.4.1 and 4.4.2).
>>
>> In KitKat, the app is killed instantly:
>> 12-12 22:04:47.386: I/ActivityManager(784): Killing 
>> 16695:/u0a80 (adj 16): remove task
>>
>> And will not run until the user manually starts the app again!
>>
>> Looking at the Android settings, Applications, Running tab shows the app 
>> as running 0 processes and 1 service. However the service is completely 
>> gone and no actual Linux process is running it. A "ps" clearly reveals it's 
>> not running. Service is not even restarted!
>>
>> The onTaskRemoved() method is called as expected and then app is 
>> permanently killed.
>>
>> On Android 4.3, the app process is killed (along with all background 
>> services), however those services returning START_STICKY are restarted as 
>> expected.
>>
>> Adding a notification icon using the foreground service flag does solves 
>> this, however the UI memory is no longer claimed and it's not the behavior 
>> that's being documented, is it?
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/11bba103-5d73-43d4-a9b6-70078b82f855%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2016-09-23 Thread Connexun India
Hello,

Can any buddy help to resolve the issue when app kill from background (by 
swipe from recent) then i am not getting any location update? This is the 
problem i am facing in Kitkat and Lollipop version of android.

I am using GoogleApiClient for location update. Also i am using in service 
for get the location.

Thanks,

Ajay

On Friday, December 13, 2013 at 2:50:34 AM UTC+5:30, 3c wrote:
>
> The swipe app out of recent tasks is supposed (as far as I understand it) 
> to terminate all activities but keep services running. This is true (and I 
> verified that behavior) until KitKat (verified on 4.4.1 and 4.4.2).
>
> In KitKat, the app is killed instantly:
> 12-12 22:04:47.386: I/ActivityManager(784): Killing 
> 16695:/u0a80 (adj 16): remove task
>
> And will not run until the user manually starts the app again!
>
> Looking at the Android settings, Applications, Running tab shows the app 
> as running 0 processes and 1 service. However the service is completely 
> gone and no actual Linux process is running it. A "ps" clearly reveals it's 
> not running. Service is not even restarted!
>
> The onTaskRemoved() method is called as expected and then app is 
> permanently killed.
>
> On Android 4.3, the app process is killed (along with all background 
> services), however those services returning START_STICKY are restarted as 
> expected.
>
> Adding a notification icon using the foreground service flag does solves 
> this, however the UI memory is no longer claimed and it's not the behavior 
> that's being documented, is it?
>

-- 
You received this message because you are subscribed to the Google Groups 
"Android Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
To post to this group, send email to android-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/android-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/android-developers/57ca7423-7bb3-431b-82a0-f4e8316e3cb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2014-01-03 Thread 3c
Just for the record Piren now that this bug has actually been verified by 
others, not just argued without testing,


I didn't insulted anyone, and didn't go into rhetoric. The original post is 
pretty clear and shows extract on actual Android dev documentation and 
actual Android verified behavior. Nevertheless initial replies where about 
showing off some unrelated links and information without even considering 
the simple information posted (or based on a single word found in the 
middle, what a joke!).

At no time I mentioned what I think swipe means, I'm just referring to a 
piece of documentation that's pretty clear on some expected behavior that 
are no longer valid.


Not a single of those replies are actually referring to the bugged behavior 
or the piece of actual documentation in original post. So who is really 
condescending or being an asshole here?


FYI: Condescending means: having or showing an attitude of patronizing 
superiority, eg telling others what to do and implying they don't 
understand shit, like the first 3 replies.


Obviously this cannot be a policy change as the information provided to the 
user is misleading (from original post: app is dead, Android says 
otherwise) and actually breaks every widget apps on market, while Google 
marked apps like HD Widgets and the likes as from great developers.


Or maybe Google wants to kill those great developers' apps and its own 
reputation in recognizing the work of others. Very doubtful.



On Sunday, December 15, 2013 9:25:06 AM UTC+1, Piren wrote:

 First, i'll have to agree with Kristopher, you're being an asshole... tone 
 down your rhetoric, people might be more inclined to help you.
 Second, you keep going on and on selling us what you think the swipe means 
 and what users think the swipe means, who cares? the only thing that 
 matters is what google thought it is, and sadly, they made practically no 
 documentation of it.

 It is however supposed to keep services running sometimes :) 
 See posts by Dianne here:
 https://plus.google.com/105051985738280261832/posts/GfwRYCC42uX

 And there's also a known bug about it here:
 https://groups.google.com/forum/#!topic/android-developers/LtmA9xbrD5A

 And what you're describing might be another bug, or just a policy change 
 which again was badly documented.
 Either way, the simplest solution to your issue will be to change the 
 service to be a Foreground Service, it should* keep the service running.

 * With google, it's always a guess


-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


[android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-22 Thread 3c
Any-one tried to use the android:persistent flag set to true in Application 
manifest? Might not really be a desired configuration, but might help some 
specific use cases.

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


[android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-17 Thread Muzikant
Try using the following code. It's a dirty workaround but it works (unless 
the process is killed via ps or DDMS - Does anyone have some sort of 
solution for that ???).

public void onTaskRemoved(Intent rootIntent)
{
Intent restartServiceIntent = new Intent(getApplicationContext(), 
this.getClass());
restartServiceIntent.setPackage(getPackageName());

PendingIntent restartServicePendingIntent = 
PendingIntent.getService(getApplicationContext(), 1, restartServiceIntent, 
PendingIntent.FLAG_ONE_SHOT);
AlarmManager alarmService = (AlarmManager) 
getApplicationContext().getSystemService(Context.ALARM_SERVICE);
alarmService.setExact(
AlarmManager.ELAPSED_REALTIME,
SystemClock.elapsedRealtime() + 1000,
restartServicePendingIntent);

super.onTaskRemoved(rootIntent);
}

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-15 Thread Piren
First, i'll have to agree with Kristopher, you're being an asshole... tone 
down your rhetoric, people might be more inclined to help you.
Second, you keep going on and on selling us what you think the swipe means 
and what users think the swipe means, who cares? the only thing that 
matters is what google thought it is, and sadly, they made practically no 
documentation of it.

It is however supposed to keep services running sometimes :) 
See posts by Dianne here:
https://plus.google.com/105051985738280261832/posts/GfwRYCC42uX

And there's also a known bug about it here:
https://groups.google.com/forum/#!topic/android-developers/LtmA9xbrD5A

And what you're describing might be another bug, or just a policy change 
which again was badly documented.
Either way, the simplest solution to your issue will be to change the 
service to be a Foreground Service, it should* keep the service running.

* With google, it's always a guess 

On Saturday, December 14, 2013 10:40:58 PM UTC+2, 3c wrote:

 And I did dig into the sources. App is permanently killed, except for 
 manifest registered events (unverified) and alarms. So any sticky device 
 not relying on those is a dead service. In 4.4.x only that is.

 I found a work around but its so dirty I wait for a better option if any 
 before posting.
 Le 14 déc. 2013 17:37, Kristopher Micinski 
 krismi...@gmail.comjavascript: 
 a écrit :

 Just as a note: you're being fairly condescending to people who are
 suggesting solutions to you free of charge in a pretty polite way..

 I personally don't know what the semantics of the swipe away are: but
 I wouldn't be surprised if it were to kill the app.  I am not sure
 whether or not I'd call it a bug or not (I'd personally lean toward
 not) but it's obvious you feel differently.  If nobody else
 (presumably, someone who's read the source..) responds to this you
 could always dig through the system source to find out!

 Kris


 On Fri, Dec 13, 2013 at 6:59 AM, 3c ccou...@gmail.com javascript: 
 wrote:
  Thanks but I'm fully aware of this and as the title suggest I'm 
 referring to
  swiping an app from the recent task list. Not sure how this has 
 anything to
  do with this.
 
  On Android 4.4, the recent task list is now acting like a force-stop and
  that's a definitive and obvious bug. And this behavior is anything but 
 what
  end-users do expect when removing apps from recent list. I've already
  received a dozen reports from end-users who think my app stops 
 functioning
  unexpectedly, while they only swiped it away from the recent list, they
  expect its services to continue running!
 
  How nice this is when an app actually has widgets on the launcher? Those
  simply stop refreshing forever! If that's not a bug, I guess Android OS 
 and
  my app both have 0 bug. I'll make sure to refer my users to your posts 
 so
  they understand there's no bug!
 
  Have a read at these:
  
 http://developer.android.com/reference/android/app/Service.html#onTaskRemoved(android.content.Intent)
  
 http://developer.android.com/reference/android/content/pm/ServiceInfo.html#FLAG_STOP_WITH_TASK
 
 
  On Friday, December 13, 2013 4:25:42 AM UTC+1, RichardC wrote:
 
  Have a read of:
 
  Launch controls on stopped applications in
  http://developer.android.com/about/versions/android-3.1.html
 
  Note that it says:
  Applications are in a stopped state when they are first installed but 
 are
  not yet launched and when they are manually stopped by the user (in 
 Manage
  Applications).
 
  This was introduced in 3.1 before we had swiping away.
 
 
  On Friday, December 13, 2013 1:22:27 AM UTC, 3c wrote:
 
  I cannot agree with this as the recent task list in no way suggest
  killing the apps. Actually every users seems to see it differently. 
 Some
  take that recent task list as the name suggest, recent tasks and 
 activities,
  others see it as you suggest an app killing, but most users don't know
  what's actually happening when removing a task from that list.
 
  Furthermore that list doesn't actually reflect apps still running, but
  the recent tasks or apps used by end-user. On boot I may have a dozen 
 apps
  running, but no way to kill them (except going into settings, 
 force-stop) if
  I haven't started them once, making this task killer the worse I've 
 ever
  seen: it requires end-user to open the app before being able to kill 
 it
  permanently! And it's not because I remove a task from that very list 
 that I
  don't want its services to continue running.
 
  Looking at documentation for the Service class and the related 
 manifest
  attributes definitely confirm the behavior of Android 4.0 to 4.3:
 
  With Android 4.4, the below flag is now ineffective, which falls into 
 the
  bug category, not the other way around as you suggest.
 
 
  public static final int stopWithTask
  Added in API level 14
 
  If set to true, this service with be automatically stopped when the 
 user
  remove a task rooted in an activity owned by the 

Re: [android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-15 Thread Kostya Vasilyev
I just did a quick test (twice, to be sure) on my Nexus 5 with 4.4.2, and
found that:

1 - Having a foreground service does not prevent the process, including the
service, from being killed

2 - The killed process does not get automatically restarted, at least not
in any reasonable timeframe

3 - To add insult to injury, the service's foreground icon stays stuck in
the status bar

4 - Existing alarms that target the package's components continue to work
(so the package is not placed in a disabled state, as someone speculated)

5 - Killing a process with DDMS behaves the same way: a foreground service
goes away with the process (that's expected), but does not get restarted
after a short time, like it did in earlier Android versions.

Item 4 makes it look like an intentional change, while the third one makes
it look like a bug.

I'm more inclined to think it's a bug, maybe caused by memory optimization
changes in the system's internals (yes, I'm speculating).

At the same time, I see things like these in the logcat:

I/ActivityManager(  758): Killing
28081:com.google.android.setupwizard/u0a17 (adj 15): empty for 1806s
I/ActivityManager(  758): Killing 28113:com.google.android.youtube/u0a73
(adj 15): empty for 1806s

It's likely that Google's apps aren't affected by this, as they often use
GCM (Gmail, G+, other cloud centric apps).

So we have substantial changes / bugs in how process lifecycles are
handled, likely to optimize memory usage, and at the same time Google's own
apps, including those built into the firmware, continue to run when they've
not been used (ever / for a long time).

-- K



2013/12/15 Piren gpi...@gmail.com

 First, i'll have to agree with Kristopher, you're being an asshole... tone
 down your rhetoric, people might be more inclined to help you.
 Second, you keep going on and on selling us what you think the swipe means
 and what users think the swipe means, who cares? the only thing that
 matters is what google thought it is, and sadly, they made practically no
 documentation of it.

 It is however supposed to keep services running sometimes :)
 See posts by Dianne here:
 https://plus.google.com/105051985738280261832/posts/GfwRYCC42uX

 And there's also a known bug about it here:
 https://groups.google.com/forum/#!topic/android-developers/LtmA9xbrD5A

 And what you're describing might be another bug, or just a policy change
 which again was badly documented.
 Either way, the simplest solution to your issue will be to change the
 service to be a Foreground Service, it should* keep the service running.

 * With google, it's always a guess

 On Saturday, December 14, 2013 10:40:58 PM UTC+2, 3c wrote:

 And I did dig into the sources. App is permanently killed, except for
 manifest registered events (unverified) and alarms. So any sticky device
 not relying on those is a dead service. In 4.4.x only that is.

 I found a work around but its so dirty I wait for a better option if any
 before posting.
 Le 14 déc. 2013 17:37, Kristopher Micinski krismi...@gmail.com a
 écrit :

 Just as a note: you're being fairly condescending to people who are
 suggesting solutions to you free of charge in a pretty polite way..

 I personally don't know what the semantics of the swipe away are: but
 I wouldn't be surprised if it were to kill the app.  I am not sure
 whether or not I'd call it a bug or not (I'd personally lean toward
 not) but it's obvious you feel differently.  If nobody else
 (presumably, someone who's read the source..) responds to this you
 could always dig through the system source to find out!

 Kris


 On Fri, Dec 13, 2013 at 6:59 AM, 3c ccou...@gmail.com wrote:
  Thanks but I'm fully aware of this and as the title suggest I'm
 referring to
  swiping an app from the recent task list. Not sure how this has
 anything to
  do with this.
 
  On Android 4.4, the recent task list is now acting like a force-stop
 and
  that's a definitive and obvious bug. And this behavior is anything but
 what
  end-users do expect when removing apps from recent list. I've already
  received a dozen reports from end-users who think my app stops
 functioning
  unexpectedly, while they only swiped it away from the recent list, they
  expect its services to continue running!
 
  How nice this is when an app actually has widgets on the launcher?
 Those
  simply stop refreshing forever! If that's not a bug, I guess Android
 OS and
  my app both have 0 bug. I'll make sure to refer my users to your posts
 so
  they understand there's no bug!
 
  Have a read at these:
  http://developer.android.com/reference/android/app/Service.
 html#onTaskRemoved(android.content.Intent)
  http://developer.android.com/reference/android/content/pm/
 ServiceInfo.html#FLAG_STOP_WITH_TASK
 
 
  On Friday, December 13, 2013 4:25:42 AM UTC+1, RichardC wrote:
 
  Have a read of:
 
  Launch controls on stopped applications in
  http://developer.android.com/about/versions/android-3.1.html
 
  Note that it says:
  Applications are in a 

Re: [android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-15 Thread Piren
Good thing i've placed that Asterisk in my post :)
Sounds like quite a bug. 



On Sunday, December 15, 2013 2:34:23 PM UTC+2, Kostya Vasilyev wrote:

 I just did a quick test (twice, to be sure) on my Nexus 5 with 4.4.2, and 
 found that:

 1 - Having a foreground service does not prevent the process, including 
 the service, from being killed

 2 - The killed process does not get automatically restarted, at least not 
 in any reasonable timeframe

 3 - To add insult to injury, the service's foreground icon stays stuck in 
 the status bar

 4 - Existing alarms that target the package's components continue to work 
 (so the package is not placed in a disabled state, as someone speculated)

 5 - Killing a process with DDMS behaves the same way: a foreground service 
 goes away with the process (that's expected), but does not get restarted 
 after a short time, like it did in earlier Android versions.

 Item 4 makes it look like an intentional change, while the third one makes 
 it look like a bug.

 I'm more inclined to think it's a bug, maybe caused by memory optimization 
 changes in the system's internals (yes, I'm speculating).

 At the same time, I see things like these in the logcat:

 I/ActivityManager(  758): Killing 
 28081:com.google.android.setupwizard/u0a17 (adj 15): empty for 1806s
 I/ActivityManager(  758): Killing 28113:com.google.android.youtube/u0a73 
 (adj 15): empty for 1806s

 It's likely that Google's apps aren't affected by this, as they often use 
 GCM (Gmail, G+, other cloud centric apps).

 So we have substantial changes / bugs in how process lifecycles are 
 handled, likely to optimize memory usage, and at the same time Google's own 
 apps, including those built into the firmware, continue to run when they've 
 not been used (ever / for a long time).

 -- K



 2013/12/15 Piren gpi...@gmail.com javascript:

 First, i'll have to agree with Kristopher, you're being an asshole... 
 tone down your rhetoric, people might be more inclined to help you.
 Second, you keep going on and on selling us what you think the swipe 
 means and what users think the swipe means, who cares? the only thing that 
 matters is what google thought it is, and sadly, they made practically no 
 documentation of it.

 It is however supposed to keep services running sometimes :) 
 See posts by Dianne here:
 https://plus.google.com/105051985738280261832/posts/GfwRYCC42uX

 And there's also a known bug about it here:
 https://groups.google.com/forum/#!topic/android-developers/LtmA9xbrD5A

 And what you're describing might be another bug, or just a policy change 
 which again was badly documented.
 Either way, the simplest solution to your issue will be to change the 
 service to be a Foreground Service, it should* keep the service running.

 * With google, it's always a guess 

 On Saturday, December 14, 2013 10:40:58 PM UTC+2, 3c wrote:

 And I did dig into the sources. App is permanently killed, except for 
 manifest registered events (unverified) and alarms. So any sticky device 
 not relying on those is a dead service. In 4.4.x only that is.

 I found a work around but its so dirty I wait for a better option if any 
 before posting.
 Le 14 déc. 2013 17:37, Kristopher Micinski krismi...@gmail.com a 
 écrit :

  Just as a note: you're being fairly condescending to people who are
 suggesting solutions to you free of charge in a pretty polite way..

 I personally don't know what the semantics of the swipe away are: but
 I wouldn't be surprised if it were to kill the app.  I am not sure
 whether or not I'd call it a bug or not (I'd personally lean toward
 not) but it's obvious you feel differently.  If nobody else
 (presumably, someone who's read the source..) responds to this you
 could always dig through the system source to find out!

 Kris


 On Fri, Dec 13, 2013 at 6:59 AM, 3c ccou...@gmail.com wrote:
  Thanks but I'm fully aware of this and as the title suggest I'm 
 referring to
  swiping an app from the recent task list. Not sure how this has 
 anything to
  do with this.
 
  On Android 4.4, the recent task list is now acting like a force-stop 
 and
  that's a definitive and obvious bug. And this behavior is anything 
 but what
  end-users do expect when removing apps from recent list. I've already
  received a dozen reports from end-users who think my app stops 
 functioning
  unexpectedly, while they only swiped it away from the recent list, 
 they
  expect its services to continue running!
 
  How nice this is when an app actually has widgets on the launcher? 
 Those
  simply stop refreshing forever! If that's not a bug, I guess Android 
 OS and
  my app both have 0 bug. I'll make sure to refer my users to your 
 posts so
  they understand there's no bug!
 
  Have a read at these:
  http://developer.android.com/reference/android/app/Service.
 html#onTaskRemoved(android.content.Intent)
  http://developer.android.com/reference/android/content/pm/
 ServiceInfo.html#FLAG_STOP_WITH_TASK
 
 
  On Friday, 

Re: [android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-15 Thread Cedric Counotte
Nice testing and investigation. Running the same device same version.

However when I set a foreground service (with the status icon) the app is
not killed!? The is actually running a plain sticky background service and
an extra foreground service.

Without foreground service the app is killed and never restarted, but
Android apps, running shows the service as still running.  Bug #1

I just tried killing the app using the stop background process api.  And
app is no longer restarted. That is both services are not scheduled for
restart.

And the foreground icon remains in the status bar. Bug #2.

IMO there is nothing consistent in the new behavior.

Not sure how Google will fix the above bugs, but if a swipe from what is
called a recent task list also kills any background sticky service, I call
this bug #3.

For me it looks like Google is trying to improve memory consumption and
battery drains with the assumption that only their apps behave well.

While I've made endless recording of Google's app and services draining
battery in standby more than any other apps. FWIW I only install my app on
any devices. And in battery usage stats can only find Google's apps and
services.

That said I can't blame Google who made Android which changed my life
completely.

Nevertheless the whole process needs fine tuning, and until then requires
workaround.

The workaround I'm using is very simple: I create a transparent activity
from onTaskRemoved to restart my services. How dirtier can it get?

Sent from GMail mobile.

Rgds,
Ç.
Le 15 déc. 2013 13:47, Kostya Vasilyev kmans...@gmail.com a écrit :

 I just did a quick test (twice, to be sure) on my Nexus 5 with 4.4.2, and
 found that:

 1 - Having a foreground service does not prevent the process, including
 the service, from being killed

 2 - The killed process does not get automatically restarted, at least not
 in any reasonable timeframe

 3 - To add insult to injury, the service's foreground icon stays stuck in
 the status bar

 4 - Existing alarms that target the package's components continue to work
 (so the package is not placed in a disabled state, as someone speculated)

 5 - Killing a process with DDMS behaves the same way: a foreground service
 goes away with the process (that's expected), but does not get restarted
 after a short time, like it did in earlier Android versions.

 Item 4 makes it look like an intentional change, while the third one makes
 it look like a bug.

 I'm more inclined to think it's a bug, maybe caused by memory optimization
 changes in the system's internals (yes, I'm speculating).

 At the same time, I see things like these in the logcat:

 I/ActivityManager(  758): Killing
 28081:com.google.android.setupwizard/u0a17 (adj 15): empty for 1806s
 I/ActivityManager(  758): Killing 28113:com.google.android.youtube/u0a73
 (adj 15): empty for 1806s

 It's likely that Google's apps aren't affected by this, as they often use
 GCM (Gmail, G+, other cloud centric apps).

 So we have substantial changes / bugs in how process lifecycles are
 handled, likely to optimize memory usage, and at the same time Google's own
 apps, including those built into the firmware, continue to run when they've
 not been used (ever / for a long time).

 -- K



 2013/12/15 Piren gpi...@gmail.com

 First, i'll have to agree with Kristopher, you're being an asshole...
 tone down your rhetoric, people might be more inclined to help you.
 Second, you keep going on and on selling us what you think the swipe
 means and what users think the swipe means, who cares? the only thing that
 matters is what google thought it is, and sadly, they made practically no
 documentation of it.

 It is however supposed to keep services running sometimes :)
 See posts by Dianne here:
 https://plus.google.com/105051985738280261832/posts/GfwRYCC42uX

 And there's also a known bug about it here:
 https://groups.google.com/forum/#!topic/android-developers/LtmA9xbrD5A

 And what you're describing might be another bug, or just a policy change
 which again was badly documented.
 Either way, the simplest solution to your issue will be to change the
 service to be a Foreground Service, it should* keep the service running.

 * With google, it's always a guess

 On Saturday, December 14, 2013 10:40:58 PM UTC+2, 3c wrote:

 And I did dig into the sources. App is permanently killed, except for
 manifest registered events (unverified) and alarms. So any sticky device
 not relying on those is a dead service. In 4.4.x only that is.

 I found a work around but its so dirty I wait for a better option if any
 before posting.
 Le 14 déc. 2013 17:37, Kristopher Micinski krismi...@gmail.com a
 écrit :

  Just as a note: you're being fairly condescending to people who are
 suggesting solutions to you free of charge in a pretty polite way..

 I personally don't know what the semantics of the swipe away are: but
 I wouldn't be surprised if it were to kill the app.  I am not sure
 whether or not I'd call it a bug or 

Re: [android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-15 Thread Kostya Vasilyev
2013/12/15 Cedric Counotte ccouno...@gmail.com

 Nice testing and investigation. Running the same device same version.

 However when I set a foreground service (with the status icon) the app is
 not killed!? The is actually running a plain sticky background service and
 an extra foreground service.


In the past, when 4.03 (or was it 4.0.1?) did its own weird stuff with
swipe from recents and background services, it was affected by intent
broadcasts. This was discussed before (Piren's link).

Maybe the important thing is here that Google's own apps continue to work.

I remember posting a list of issues with GPU acceleration that I ran into,
and the response was but all built-in apps work with it just fine.

-- K



 Without foreground service the app is killed and never restarted, but
 Android apps, running shows the service as still running.  Bug #1

 I just tried killing the app using the stop background process api.  And
 app is no longer restarted. That is both services are not scheduled for
 restart.

 And the foreground icon remains in the status bar. Bug #2.

 IMO there is nothing consistent in the new behavior.

 Not sure how Google will fix the above bugs, but if a swipe from what is
 called a recent task list also kills any background sticky service, I call
 this bug #3.

 For me it looks like Google is trying to improve memory consumption and
 battery drains with the assumption that only their apps behave well.

 While I've made endless recording of Google's app and services draining
 battery in standby more than any other apps. FWIW I only install my app on
 any devices. And in battery usage stats can only find Google's apps and
 services.

 That said I can't blame Google who made Android which changed my life
 completely.

 Nevertheless the whole process needs fine tuning, and until then requires
 workaround.

 The workaround I'm using is very simple: I create a transparent activity
 from onTaskRemoved to restart my services. How dirtier can it get?

 Sent from GMail mobile.

 Rgds,
 Ç.
 Le 15 déc. 2013 13:47, Kostya Vasilyev kmans...@gmail.com a écrit :

 I just did a quick test (twice, to be sure) on my Nexus 5 with 4.4.2, and
 found that:

 1 - Having a foreground service does not prevent the process, including
 the service, from being killed

 2 - The killed process does not get automatically restarted, at least not
 in any reasonable timeframe

 3 - To add insult to injury, the service's foreground icon stays stuck in
 the status bar

 4 - Existing alarms that target the package's components continue to work
 (so the package is not placed in a disabled state, as someone speculated)

 5 - Killing a process with DDMS behaves the same way: a foreground
 service goes away with the process (that's expected), but does not get
 restarted after a short time, like it did in earlier Android versions.

 Item 4 makes it look like an intentional change, while the third one
 makes it look like a bug.

 I'm more inclined to think it's a bug, maybe caused by memory
 optimization changes in the system's internals (yes, I'm speculating).

 At the same time, I see things like these in the logcat:

 I/ActivityManager(  758): Killing
 28081:com.google.android.setupwizard/u0a17 (adj 15): empty for 1806s
 I/ActivityManager(  758): Killing 28113:com.google.android.youtube/u0a73
 (adj 15): empty for 1806s

 It's likely that Google's apps aren't affected by this, as they often use
 GCM (Gmail, G+, other cloud centric apps).

 So we have substantial changes / bugs in how process lifecycles are
 handled, likely to optimize memory usage, and at the same time Google's own
 apps, including those built into the firmware, continue to run when they've
 not been used (ever / for a long time).

 -- K



 2013/12/15 Piren gpi...@gmail.com

 First, i'll have to agree with Kristopher, you're being an asshole...
 tone down your rhetoric, people might be more inclined to help you.
 Second, you keep going on and on selling us what you think the swipe
 means and what users think the swipe means, who cares? the only thing that
 matters is what google thought it is, and sadly, they made practically no
 documentation of it.

 It is however supposed to keep services running sometimes :)
 See posts by Dianne here:
 https://plus.google.com/105051985738280261832/posts/GfwRYCC42uX

 And there's also a known bug about it here:
 https://groups.google.com/forum/#!topic/android-developers/LtmA9xbrD5A

 And what you're describing might be another bug, or just a policy change
 which again was badly documented.
 Either way, the simplest solution to your issue will be to change the
 service to be a Foreground Service, it should* keep the service running.

 * With google, it's always a guess

 On Saturday, December 14, 2013 10:40:58 PM UTC+2, 3c wrote:

 And I did dig into the sources. App is permanently killed, except for
 manifest registered events (unverified) and alarms. So any sticky device
 not relying on those is a dead service. In 

[android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-14 Thread VenomVendor™
You have to use 
*START_STICKY*http://developer.android.com/reference/android/app/Service.html#START_STICKYwhich
 is a sticky service, also add flag *FLAG_FROM_BACKGROUND 
http://developer.android.com/reference/android/content/Intent.html#FLAG_FROM_BACKGROUND*while
 starting your service. when you use START_STICKY make sure you do not 
pass any data via intent, since your app/activity is killed, but you can 
re-start the service. 
Ex : you need to read the values from Sensors and do operations. all the 
values are generated within the service only.

@Override
public int onStartCommand(Intent intent, int flags, int startId) {
// We want this service to continue running until it is explicitly 
stopped, so return sticky.
return START_STICKY;
}


you have to call *stopService(); 
http://developer.android.com/reference/android/content/Context.html#stopService%28android.content.Intent%29*manually
 to kill the service, else you will use huge memory.

-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-14 Thread Kristopher Micinski
Just as a note: you're being fairly condescending to people who are
suggesting solutions to you free of charge in a pretty polite way..

I personally don't know what the semantics of the swipe away are: but
I wouldn't be surprised if it were to kill the app.  I am not sure
whether or not I'd call it a bug or not (I'd personally lean toward
not) but it's obvious you feel differently.  If nobody else
(presumably, someone who's read the source..) responds to this you
could always dig through the system source to find out!

Kris


On Fri, Dec 13, 2013 at 6:59 AM, 3c ccouno...@gmail.com wrote:
 Thanks but I'm fully aware of this and as the title suggest I'm referring to
 swiping an app from the recent task list. Not sure how this has anything to
 do with this.

 On Android 4.4, the recent task list is now acting like a force-stop and
 that's a definitive and obvious bug. And this behavior is anything but what
 end-users do expect when removing apps from recent list. I've already
 received a dozen reports from end-users who think my app stops functioning
 unexpectedly, while they only swiped it away from the recent list, they
 expect its services to continue running!

 How nice this is when an app actually has widgets on the launcher? Those
 simply stop refreshing forever! If that's not a bug, I guess Android OS and
 my app both have 0 bug. I'll make sure to refer my users to your posts so
 they understand there's no bug!

 Have a read at these:
 http://developer.android.com/reference/android/app/Service.html#onTaskRemoved(android.content.Intent)
 http://developer.android.com/reference/android/content/pm/ServiceInfo.html#FLAG_STOP_WITH_TASK


 On Friday, December 13, 2013 4:25:42 AM UTC+1, RichardC wrote:

 Have a read of:

 Launch controls on stopped applications in
 http://developer.android.com/about/versions/android-3.1.html

 Note that it says:
 Applications are in a stopped state when they are first installed but are
 not yet launched and when they are manually stopped by the user (in Manage
 Applications).

 This was introduced in 3.1 before we had swiping away.


 On Friday, December 13, 2013 1:22:27 AM UTC, 3c wrote:

 I cannot agree with this as the recent task list in no way suggest
 killing the apps. Actually every users seems to see it differently. Some
 take that recent task list as the name suggest, recent tasks and activities,
 others see it as you suggest an app killing, but most users don't know
 what's actually happening when removing a task from that list.

 Furthermore that list doesn't actually reflect apps still running, but
 the recent tasks or apps used by end-user. On boot I may have a dozen apps
 running, but no way to kill them (except going into settings, force-stop) if
 I haven't started them once, making this task killer the worse I've ever
 seen: it requires end-user to open the app before being able to kill it
 permanently! And it's not because I remove a task from that very list that I
 don't want its services to continue running.

 Looking at documentation for the Service class and the related manifest
 attributes definitely confirm the behavior of Android 4.0 to 4.3:

 With Android 4.4, the below flag is now ineffective, which falls into the
 bug category, not the other way around as you suggest.


 public static final int stopWithTask
 Added in API level 14

 If set to true, this service with be automatically stopped when the user
 remove a task rooted in an activity owned by the application. The default is
 false.

 Must be a boolean value, either true or false.

 public void onTaskRemoved (Intent rootIntent)

 Added in API level 14

 This is called if the service is currently running and the user has
 removed a task that comes from the service's application. If you have set
 ServiceInfo.FLAG_STOP_WITH_TASK then you will not receive this callback;
 instead, the service will simply be stopped.


 --
 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
 ---
 You received this message because you are subscribed to the Google Groups
 Android Developers group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to android-developers+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.

-- 
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
--- 
You received this message because you are 

Re: [android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-14 Thread Cedric Counotte
So far I didn't see any solution, only reference to documentation that's
unrelated. So talking about condescending...

And its as if no one even care to read the actual documentation that
relates to this issue which I've clearly posted.

As if I didn't know what force stop was doing or if my services where not
sticky services... Which is clearly stated too.

I'll check the suggested option to set from background flag if it actually
helps.
 Le 14 déc. 2013 17:37, Kristopher Micinski krismicin...@gmail.com a
écrit :

 Just as a note: you're being fairly condescending to people who are
 suggesting solutions to you free of charge in a pretty polite way..

 I personally don't know what the semantics of the swipe away are: but
 I wouldn't be surprised if it were to kill the app.  I am not sure
 whether or not I'd call it a bug or not (I'd personally lean toward
 not) but it's obvious you feel differently.  If nobody else
 (presumably, someone who's read the source..) responds to this you
 could always dig through the system source to find out!

 Kris


 On Fri, Dec 13, 2013 at 6:59 AM, 3c ccouno...@gmail.com wrote:
  Thanks but I'm fully aware of this and as the title suggest I'm
 referring to
  swiping an app from the recent task list. Not sure how this has anything
 to
  do with this.
 
  On Android 4.4, the recent task list is now acting like a force-stop and
  that's a definitive and obvious bug. And this behavior is anything but
 what
  end-users do expect when removing apps from recent list. I've already
  received a dozen reports from end-users who think my app stops
 functioning
  unexpectedly, while they only swiped it away from the recent list, they
  expect its services to continue running!
 
  How nice this is when an app actually has widgets on the launcher? Those
  simply stop refreshing forever! If that's not a bug, I guess Android OS
 and
  my app both have 0 bug. I'll make sure to refer my users to your posts so
  they understand there's no bug!
 
  Have a read at these:
 
 http://developer.android.com/reference/android/app/Service.html#onTaskRemoved(android.content.Intent)
 
 http://developer.android.com/reference/android/content/pm/ServiceInfo.html#FLAG_STOP_WITH_TASK
 
 
  On Friday, December 13, 2013 4:25:42 AM UTC+1, RichardC wrote:
 
  Have a read of:
 
  Launch controls on stopped applications in
  http://developer.android.com/about/versions/android-3.1.html
 
  Note that it says:
  Applications are in a stopped state when they are first installed but
 are
  not yet launched and when they are manually stopped by the user (in
 Manage
  Applications).
 
  This was introduced in 3.1 before we had swiping away.
 
 
  On Friday, December 13, 2013 1:22:27 AM UTC, 3c wrote:
 
  I cannot agree with this as the recent task list in no way suggest
  killing the apps. Actually every users seems to see it differently.
 Some
  take that recent task list as the name suggest, recent tasks and
 activities,
  others see it as you suggest an app killing, but most users don't know
  what's actually happening when removing a task from that list.
 
  Furthermore that list doesn't actually reflect apps still running, but
  the recent tasks or apps used by end-user. On boot I may have a dozen
 apps
  running, but no way to kill them (except going into settings,
 force-stop) if
  I haven't started them once, making this task killer the worse I've
 ever
  seen: it requires end-user to open the app before being able to kill it
  permanently! And it's not because I remove a task from that very list
 that I
  don't want its services to continue running.
 
  Looking at documentation for the Service class and the related manifest
  attributes definitely confirm the behavior of Android 4.0 to 4.3:
 
  With Android 4.4, the below flag is now ineffective, which falls into
 the
  bug category, not the other way around as you suggest.
 
 
  public static final int stopWithTask
  Added in API level 14
 
  If set to true, this service with be automatically stopped when the
 user
  remove a task rooted in an activity owned by the application. The
 default is
  false.
 
  Must be a boolean value, either true or false.
 
  public void onTaskRemoved (Intent rootIntent)
 
  Added in API level 14
 
  This is called if the service is currently running and the user has
  removed a task that comes from the service's application. If you have
 set
  ServiceInfo.FLAG_STOP_WITH_TASK then you will not receive this
 callback;
  instead, the service will simply be stopped.
 
 
  --
  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
  ---
  You received this message because you are subscribed to the Google Groups
  Android 

Re: [android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-14 Thread Cedric Counotte
And I did dig into the sources. App is permanently killed, except for
manifest registered events (unverified) and alarms. So any sticky device
not relying on those is a dead service. In 4.4.x only that is.

I found a work around but its so dirty I wait for a better option if any
before posting.
Le 14 déc. 2013 17:37, Kristopher Micinski krismicin...@gmail.com a
écrit :

 Just as a note: you're being fairly condescending to people who are
 suggesting solutions to you free of charge in a pretty polite way..

 I personally don't know what the semantics of the swipe away are: but
 I wouldn't be surprised if it were to kill the app.  I am not sure
 whether or not I'd call it a bug or not (I'd personally lean toward
 not) but it's obvious you feel differently.  If nobody else
 (presumably, someone who's read the source..) responds to this you
 could always dig through the system source to find out!

 Kris


 On Fri, Dec 13, 2013 at 6:59 AM, 3c ccouno...@gmail.com wrote:
  Thanks but I'm fully aware of this and as the title suggest I'm
 referring to
  swiping an app from the recent task list. Not sure how this has anything
 to
  do with this.
 
  On Android 4.4, the recent task list is now acting like a force-stop and
  that's a definitive and obvious bug. And this behavior is anything but
 what
  end-users do expect when removing apps from recent list. I've already
  received a dozen reports from end-users who think my app stops
 functioning
  unexpectedly, while they only swiped it away from the recent list, they
  expect its services to continue running!
 
  How nice this is when an app actually has widgets on the launcher? Those
  simply stop refreshing forever! If that's not a bug, I guess Android OS
 and
  my app both have 0 bug. I'll make sure to refer my users to your posts so
  they understand there's no bug!
 
  Have a read at these:
 
 http://developer.android.com/reference/android/app/Service.html#onTaskRemoved(android.content.Intent)
 
 http://developer.android.com/reference/android/content/pm/ServiceInfo.html#FLAG_STOP_WITH_TASK
 
 
  On Friday, December 13, 2013 4:25:42 AM UTC+1, RichardC wrote:
 
  Have a read of:
 
  Launch controls on stopped applications in
  http://developer.android.com/about/versions/android-3.1.html
 
  Note that it says:
  Applications are in a stopped state when they are first installed but
 are
  not yet launched and when they are manually stopped by the user (in
 Manage
  Applications).
 
  This was introduced in 3.1 before we had swiping away.
 
 
  On Friday, December 13, 2013 1:22:27 AM UTC, 3c wrote:
 
  I cannot agree with this as the recent task list in no way suggest
  killing the apps. Actually every users seems to see it differently.
 Some
  take that recent task list as the name suggest, recent tasks and
 activities,
  others see it as you suggest an app killing, but most users don't know
  what's actually happening when removing a task from that list.
 
  Furthermore that list doesn't actually reflect apps still running, but
  the recent tasks or apps used by end-user. On boot I may have a dozen
 apps
  running, but no way to kill them (except going into settings,
 force-stop) if
  I haven't started them once, making this task killer the worse I've
 ever
  seen: it requires end-user to open the app before being able to kill it
  permanently! And it's not because I remove a task from that very list
 that I
  don't want its services to continue running.
 
  Looking at documentation for the Service class and the related manifest
  attributes definitely confirm the behavior of Android 4.0 to 4.3:
 
  With Android 4.4, the below flag is now ineffective, which falls into
 the
  bug category, not the other way around as you suggest.
 
 
  public static final int stopWithTask
  Added in API level 14
 
  If set to true, this service with be automatically stopped when the
 user
  remove a task rooted in an activity owned by the application. The
 default is
  false.
 
  Must be a boolean value, either true or false.
 
  public void onTaskRemoved (Intent rootIntent)
 
  Added in API level 14
 
  This is called if the service is currently running and the user has
  removed a task that comes from the service's application. If you have
 set
  ServiceInfo.FLAG_STOP_WITH_TASK then you will not receive this
 callback;
  instead, the service will simply be stopped.
 
 
  --
  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
  ---
  You received this message because you are subscribed to the Google Groups
  Android Developers group.
  To unsubscribe from this group and stop receiving emails from it, send an
  email to 

[android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-13 Thread 3c
Thanks but I'm fully aware of this and as the title suggest I'm referring 
to swiping an app from the recent task list. Not sure how this has anything 
to do with this.

On Android 4.4, the recent task list is now acting like a force-stop and 
that's a definitive and obvious bug. And this behavior is anything but what 
end-users do expect when removing apps from recent list. I've already 
received a dozen reports from end-users who think my app stops functioning 
unexpectedly, while they only swiped it away from the recent list, they 
expect its services to continue running!

How nice this is when an app actually has widgets on the launcher? Those 
simply stop refreshing forever! If that's not a bug, I guess Android OS and 
my app both have 0 bug. I'll make sure to refer my users to your posts so 
they understand there's no bug!

Have a read at these: 
http://developer.android.com/reference/android/app/Service.html#onTaskRemoved(android.content.Intent)
http://developer.android.com/reference/android/content/pm/ServiceInfo.html#FLAG_STOP_WITH_TASK


On Friday, December 13, 2013 4:25:42 AM UTC+1, RichardC wrote:

 Have a read of:

 Launch controls on stopped applications in
 http://developer.android.com/about/versions/android-3.1.html

 Note that it says:
 *Applications are in a stopped state when they are first installed but 
 are not yet launched and when they are manually stopped by the user (in 
 Manage Applications).*

 This was introduced in 3.1 before we had swiping away.


 On Friday, December 13, 2013 1:22:27 AM UTC, 3c wrote:

 I cannot agree with this as the recent task list in no way suggest 
 killing the apps. Actually every users seems to see it differently. Some 
 take that recent task list as the name suggest, recent tasks and 
 activities, others see it as you suggest an app killing, but most users 
 don't know what's actually happening when removing a task from that list. 

 Furthermore that list doesn't actually reflect apps still running, but 
 the recent tasks or apps used by end-user. On boot I may have a dozen apps 
 running, but no way to kill them (except going into settings, force-stop) 
 if I haven't started them once, making this task killer the worse I've ever 
 seen: it requires end-user to open the app before being able to kill it 
 permanently! And it's not because I remove a task from that very list that 
 I don't want its services to continue running.

 Looking at documentation for the Service class and the related manifest 
 attributes definitely confirm the behavior of Android 4.0 to 4.3:

 With Android 4.4, the below flag is now ineffective, which falls into the 
 bug category, not the other way around as you suggest. 


 public static final int stopWithTask
 Added in API level 
 14http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

 If set to true, this service with be automatically stopped when the user 
 remove a task rooted in an activity owned by the application. The default 
 is false.

 Must be a boolean value, either true or false.
 public void onTaskRemoved 
 (Intenthttp://developer.android.com/reference/android/content/Intent.html
  rootIntent)
 Added in API level 
 14http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

 This is called if the service is currently running and the user has 
 removed a task that comes from the service's application. If you have set 
 ServiceInfo.FLAG_STOP_WITH_TASKhttp://developer.android.com/reference/android/content/pm/ServiceInfo.html#FLAG_STOP_WITH_TASK
  then 
 you will not receive this callback; instead, the service will simply be 
 stopped.




-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


[android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-12 Thread RichardC
Based on the blog post when the task killing of applications was 
introduced, I would say that restarting a service of a killed application 
(process) was an implementation bug.  It was clear from the blog post that 
when and end-user task killed an application then that application (and 
all components of it) should not run again until manually started.  

The clear intent was to give end-users control of sticky applications 
that would just not stop and allow them to be terminated.

On Thursday, December 12, 2013 9:20:34 PM UTC, 3c wrote:

 The swipe app out of recent tasks is supposed (as far as I understand it) 
 to terminate all activities but keep services running. This is true (and I 
 verified that behavior) until KitKat (verified on 4.4.1 and 4.4.2).

 In KitKat, the app is killed instantly:
 12-12 22:04:47.386: I/ActivityManager(784): Killing 
 16695:package_name/u0a80 (adj 16): remove task

 And will not run until the user manually starts the app again!

 Looking at the Android settings, Applications, Running tab shows the app 
 as running 0 processes and 1 service. However the service is completely 
 gone and no actual Linux process is running it. A ps clearly reveals it's 
 not running. Service is not even restarted!

 The onTaskRemoved() method is called as expected and then app is 
 permanently killed.

 On Android 4.3, the app process is killed (along with all background 
 services), however those services returning START_STICKY are restarted as 
 expected.

 Adding a notification icon using the foreground service flag does solves 
 this, however the UI memory is no longer claimed and it's not the behavior 
 that's being documented, is it?


-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


[android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-12 Thread 3c
I cannot agree with this as the recent task list in no way suggest killing 
the apps. Actually every users seems to see it differently. Some take that 
recent task list as the name suggest, recent tasks and activities, others 
see it as you suggest an app killing, but most users don't know what's 
actually happening when removing a task from that list. 

Furthermore that list doesn't actually reflect apps still running, but the 
recent tasks or apps used by end-user. On boot I may have a dozen apps 
running, but no way to kill them (except going into settings, force-stop) 
if I haven't started them once, making this task killer the worse I've ever 
seen: it requires end-user to open the app before being able to kill it 
permanently! And it's not because I remove a task from that very list that 
I don't want its services to continue running.

Looking at documentation for the Service class and the related manifest 
attributes definitely confirm the behavior of Android 4.0 to 4.3:

With Android 4.4, the below flag is now ineffective, which falls into the 
bug category, not the other way around as you suggest. 


public static final int stopWithTask
Added in API level 
14http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

If set to true, this service with be automatically stopped when the user 
remove a task rooted in an activity owned by the application. The default 
is false.

Must be a boolean value, either true or false.
public void onTaskRemoved 
(Intenthttp://developer.android.com/reference/android/content/Intent.html
 rootIntent)
Added in API level 
14http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

This is called if the service is currently running and the user has removed 
a task that comes from the service's application. If you have set 
ServiceInfo.FLAG_STOP_WITH_TASKhttp://developer.android.com/reference/android/content/pm/ServiceInfo.html#FLAG_STOP_WITH_TASK
 then 
you will not receive this callback; instead, the service will simply be 
stopped.


-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


[android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-12 Thread RichardC
Have a read of:

Launch controls on stopped applications in
http://developer.android.com/about/versions/android-3.1.html

Note that it says:
*Applications are in a stopped state when they are first installed but are 
not yet launched and when they are manually stopped by the user (in Manage 
Applications).*

This was introduced in 3.1 before we had swiping away.


On Friday, December 13, 2013 1:22:27 AM UTC, 3c wrote:

 I cannot agree with this as the recent task list in no way suggest killing 
 the apps. Actually every users seems to see it differently. Some take that 
 recent task list as the name suggest, recent tasks and activities, others 
 see it as you suggest an app killing, but most users don't know what's 
 actually happening when removing a task from that list. 

 Furthermore that list doesn't actually reflect apps still running, but the 
 recent tasks or apps used by end-user. On boot I may have a dozen apps 
 running, but no way to kill them (except going into settings, force-stop) 
 if I haven't started them once, making this task killer the worse I've ever 
 seen: it requires end-user to open the app before being able to kill it 
 permanently! And it's not because I remove a task from that very list that 
 I don't want its services to continue running.

 Looking at documentation for the Service class and the related manifest 
 attributes definitely confirm the behavior of Android 4.0 to 4.3:

 With Android 4.4, the below flag is now ineffective, which falls into the 
 bug category, not the other way around as you suggest. 


 public static final int stopWithTask
 Added in API level 
 14http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

 If set to true, this service with be automatically stopped when the user 
 remove a task rooted in an activity owned by the application. The default 
 is false.

 Must be a boolean value, either true or false.
 public void onTaskRemoved 
 (Intenthttp://developer.android.com/reference/android/content/Intent.html
  rootIntent)
 Added in API level 
 14http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

 This is called if the service is currently running and the user has 
 removed a task that comes from the service's application. If you have set 
 ServiceInfo.FLAG_STOP_WITH_TASKhttp://developer.android.com/reference/android/content/pm/ServiceInfo.html#FLAG_STOP_WITH_TASK
  then 
 you will not receive this callback; instead, the service will simply be 
 stopped.




-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [android-developers] Re: Swipe app out of recent tasks permanently kills app (like force-stop) even though it's running background services!

2013-12-12 Thread Cedric Counotte
Yeah thanks but no thanks. I'm fully aware of that.

I'm talking about the recent task list. Removing an app from that list does
like a force stop on KitKat.

Why don't you read what I wrote in the first place?
Le 13 déc. 2013 04:35, RichardC richard.crit...@googlemail.com a écrit :

 Have a read of:

 Launch controls on stopped applications in
 http://developer.android.com/about/versions/android-3.1.html

 Note that it says:
 *Applications are in a stopped state when they are first installed but
 are not yet launched and when they are manually stopped by the user (in
 Manage Applications).*

 This was introduced in 3.1 before we had swiping away.


 On Friday, December 13, 2013 1:22:27 AM UTC, 3c wrote:

 I cannot agree with this as the recent task list in no way suggest
 killing the apps. Actually every users seems to see it differently. Some
 take that recent task list as the name suggest, recent tasks and
 activities, others see it as you suggest an app killing, but most users
 don't know what's actually happening when removing a task from that list.

 Furthermore that list doesn't actually reflect apps still running, but
 the recent tasks or apps used by end-user. On boot I may have a dozen apps
 running, but no way to kill them (except going into settings, force-stop)
 if I haven't started them once, making this task killer the worse I've ever
 seen: it requires end-user to open the app before being able to kill it
 permanently! And it's not because I remove a task from that very list that
 I don't want its services to continue running.

 Looking at documentation for the Service class and the related manifest
 attributes definitely confirm the behavior of Android 4.0 to 4.3:

 With Android 4.4, the below flag is now ineffective, which falls into the
 bug category, not the other way around as you suggest.


 public static final int stopWithTask
 Added in API level 
 14http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

 If set to true, this service with be automatically stopped when the user
 remove a task rooted in an activity owned by the application. The default
 is false.

 Must be a boolean value, either true or false.
 public void onTaskRemoved 
 (Intenthttp://developer.android.com/reference/android/content/Intent.html
  rootIntent)
 Added in API level 
 14http://developer.android.com/guide/topics/manifest/uses-sdk-element.html#ApiLevels

 This is called if the service is currently running and the user has
 removed a task that comes from the service's application. If you have set
 ServiceInfo.FLAG_STOP_WITH_TASKhttp://developer.android.com/reference/android/content/pm/ServiceInfo.html#FLAG_STOP_WITH_TASK
  then
 you will not receive this callback; instead, the service will simply be
 stopped.


  --
 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
 ---
 You received this message because you are subscribed to a topic in the
 Google Groups Android Developers group.
 To unsubscribe from this topic, visit
 https://groups.google.com/d/topic/android-developers/H-DSQ4-tiac/unsubscribe
 .
 To unsubscribe from this group and all its topics, send an email to
 android-developers+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/groups/opt_out.


-- 
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
--- 
You received this message because you are subscribed to the Google Groups 
Android Developers group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to android-developers+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.