Obsolete
Status Update
Comments
le...@googlemail.com <le...@googlemail.com> #2
Thank you for suggesting this enhancement. We value the feedback from our community and hope to review your suggestion in an upcoming sprint.
ta...@gmail.com <ta...@gmail.com> #3
Good idea!
no...@gmail.com <no...@gmail.com> #4
Fixed for an upcoming 3.2 canary by Change-Id: I93b86823b3311b2214da50fdcae7deb4fc095729 . Thanks for the suggestion!
an...@gmail.com <an...@gmail.com> #6
This issue is also occurring when the AlarmManager sends the Service a broadcast.
nw...@gmail.com <nw...@gmail.com> #7
I got this to work by using the following code:
AlarmManager almgr = (AlarmManager)MyContext.getSystemService(Context.ALARM_SERVICE);
Intent timerIntent = new Intent(MyUniqueLabel);
timerIntent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
PendingIntent pendingOffLoadIntent = PendingIntent.getBroadcast(MyContext, 1, timerIntent, 0);
you MUST do these things for it to work.
1.) Call addFlags and the intent and pass it in FLAG_RECEIVER_FORGROUND
2.) Use a non-zero request code in PendingIntent.getBroadcast
If you leave any of those steps out it will not work.
AlarmManager almgr = (AlarmManager)MyContext.getSystemService(Context.ALARM_SERVICE);
Intent timerIntent = new Intent(MyUniqueLabel);
timerIntent.addFlags(Intent.FLAG_RECEIVER_FOREGROUND);
PendingIntent pendingOffLoadIntent = PendingIntent.getBroadcast(MyContext, 1, timerIntent, 0);
you MUST do these things for it to work.
1.) Call addFlags and the intent and pass it in FLAG_RECEIVER_FORGROUND
2.) Use a non-zero request code in PendingIntent.getBroadcast
If you leave any of those steps out it will not work.
de...@gmail.com <de...@gmail.com> #8
[Comment deleted]
de...@gmail.com <de...@gmail.com> #9
[Comment deleted]
de...@gmail.com <de...@gmail.com> #10
[Comment deleted]
nw...@gmail.com <nw...@gmail.com> #11
I will test this on Android 4.4 when I get a chance, currently I am only
working on 4.3
working on 4.3
gl...@gmail.com <gl...@gmail.com> #12
As a regular user I have found this bug to seriously affect my android experience.
I use some apps such as Screebl, Media Button Router, and GPS Monitor, which rely on running a service (starting automatically on boot), but since KitKat (I'm running 4.4.2) if I launch the respective app to change a setting, and then swipe it away, the service is killed permanently.
I'm used to periodically swiping things clean in the task manager, but now I have to remember if a particular app is associated with a service and avoid swiping it. I find myself resorting to reboots to make my task manager clean so I don't swipe services away by mistake!!!
Mail doesn't stop coming in if we swipe away the mail or gmail apps, so the expectation is that GPS Monitor or other service-apps shouldn't stop either. We always have the option to force stop something from the settings if we want to permanently kill the service.
KitKat, in the attempt to lower memory requirements to 512mb, has in various ways resulted in a poor and inconsistent experience. I paid for a device with 2gb of ram because I actually want many things loaded and running.
On a related note, I used to open a contact in People or the Phone app, and then hit the home button, specifically so I could quickly return to that particular contact via the task manager. Since KitKat this no longer works either, these apps start from scratch and I have to search the contact all over again. That's terrible.
I use some apps such as Screebl, Media Button Router, and GPS Monitor, which rely on running a service (starting automatically on boot), but since KitKat (I'm running 4.4.2) if I launch the respective app to change a setting, and then swipe it away, the service is killed permanently.
I'm used to periodically swiping things clean in the task manager, but now I have to remember if a particular app is associated with a service and avoid swiping it. I find myself resorting to reboots to make my task manager clean so I don't swipe services away by mistake!!!
Mail doesn't stop coming in if we swipe away the mail or gmail apps, so the expectation is that GPS Monitor or other service-apps shouldn't stop either. We always have the option to force stop something from the settings if we want to permanently kill the service.
KitKat, in the attempt to lower memory requirements to 512mb, has in various ways resulted in a poor and inconsistent experience. I paid for a device with 2gb of ram because I actually want many things loaded and running.
On a related note, I used to open a contact in People or the Phone app, and then hit the home button, specifically so I could quickly return to that particular contact via the task manager. Since KitKat this no longer works either, these apps start from scratch and I have to search the contact all over again. That's terrible.
gl...@gmail.com <gl...@gmail.com> #13
ya...@gmail.com <ya...@gmail.com> #14
Tested the solution on comment https://code.google.com/p/android/issues/detail?id=53313#c7 and that seems to work on KitKat !
Note that the FLAG_RECEIVER_FORGROUND was added on API 16 (Jelly Bean) so it makes sense that this is when the bug first appeared...
Note that the FLAG_RECEIVER_FORGROUND was added on API 16 (Jelly Bean) so it makes sense that this is when the bug first appeared...
ni...@gmail.com <ni...@gmail.com> #15
Still seeing this on 4.4.3:
06-16 21:47:39.510 I/PackageManager(880): Action: "android.intent.action.SENDTO"
06-16 21:47:39.510 I/PackageManager(880): Category: "android.intent.category.DEFAULT"
06-16 21:47:39.510 I/PackageManager(880): Scheme: "sms"
06-16 21:47:39.510 I/PackageManager(880): Adding preferred activity ComponentInfo{com.google.android.talk/com.google.android.apps.babel.phone.BabelHomeActivity} for user 0 :
06-16 21:47:39.530 I/MMSContentObserver(29156): strStoredPrevMMSIds[916,27464,27465,27466,27446,27447,27449,27451,27453,27293], id=916
06-16 21:47:39.530 I/PackageManager(880): Action: "android.intent.action.SENDTO"
06-16 21:47:39.530 I/PackageManager(880): Category: "android.intent.category.DEFAULT"
06-16 21:47:39.530 I/PackageManager(880): Scheme: "smsto"
06-16 21:47:39.530 I/PackageManager(880): Adding preferred activity ComponentInfo{com.google.android.talk/com.google.android.apps.babel.phone.BabelHomeActivity} for user 0 :
06-16 21:47:39.580 I/PackageManager(880): Action: "android.intent.action.SENDTO"
06-16 21:47:39.580 I/PackageManager(880): Category: "android.intent.category.DEFAULT"
06-16 21:47:39.580 I/PackageManager(880): Scheme: "mms"
06-16 21:47:39.580 I/PackageManager(880): Adding preferred activity ComponentInfo{com.google.android.talk/com.google.android.apps.babel.phone.BabelHomeActivity} for user 0 :
06-16 21:47:39.610 I/PackageManager(880): Action: "android.intent.action.SENDTO"
06-16 21:47:39.610 I/PackageManager(880): Category: "android.intent.category.DEFAULT"
06-16 21:47:39.610 I/PackageManager(880): Scheme: "mmsto"
06-16 21:47:39.610 I/PackageManager(880): Adding preferred activity ComponentInfo{com.google.android.talk/com.google.android.apps.babel.phone.BabelHomeActivity} for user 0 :
06-16 21:47:39.620 I/MMSContentObserver(29156): strStoredPrevMMSIds[916,27464,27465,27466,27446,27447,27449,27451,27453,27293], id=916
06-16 21:47:39.640 I/ActivityManager(880): Killing 31153:com.google.android.talk/u0a76 (adj 9): 63984k from cached
Hangouts gets killed and never receives the SMS broadcast, so the message never gets saved to the SMS content store and is lost forever (and the user gets no indication this is happening).
06-16 21:47:39.510 I/PackageManager(880): Action: "android.intent.action.SENDTO"
06-16 21:47:39.510 I/PackageManager(880): Category: "android.intent.category.DEFAULT"
06-16 21:47:39.510 I/PackageManager(880): Scheme: "sms"
06-16 21:47:39.510 I/PackageManager(880): Adding preferred activity ComponentInfo{com.google.android.talk/com.google.android.apps.babel.phone.BabelHomeActivity} for user 0 :
06-16 21:47:39.530 I/MMSContentObserver(29156): strStoredPrevMMSIds[916,27464,27465,27466,27446,27447,27449,27451,27453,27293], id=916
06-16 21:47:39.530 I/PackageManager(880): Action: "android.intent.action.SENDTO"
06-16 21:47:39.530 I/PackageManager(880): Category: "android.intent.category.DEFAULT"
06-16 21:47:39.530 I/PackageManager(880): Scheme: "smsto"
06-16 21:47:39.530 I/PackageManager(880): Adding preferred activity ComponentInfo{com.google.android.talk/com.google.android.apps.babel.phone.BabelHomeActivity} for user 0 :
06-16 21:47:39.580 I/PackageManager(880): Action: "android.intent.action.SENDTO"
06-16 21:47:39.580 I/PackageManager(880): Category: "android.intent.category.DEFAULT"
06-16 21:47:39.580 I/PackageManager(880): Scheme: "mms"
06-16 21:47:39.580 I/PackageManager(880): Adding preferred activity ComponentInfo{com.google.android.talk/com.google.android.apps.babel.phone.BabelHomeActivity} for user 0 :
06-16 21:47:39.610 I/PackageManager(880): Action: "android.intent.action.SENDTO"
06-16 21:47:39.610 I/PackageManager(880): Category: "android.intent.category.DEFAULT"
06-16 21:47:39.610 I/PackageManager(880): Scheme: "mmsto"
06-16 21:47:39.610 I/PackageManager(880): Adding preferred activity ComponentInfo{com.google.android.talk/com.google.android.apps.babel.phone.BabelHomeActivity} for user 0 :
06-16 21:47:39.620 I/MMSContentObserver(29156): strStoredPrevMMSIds[916,27464,27465,27466,27446,27447,27449,27451,27453,27293], id=916
06-16 21:47:39.640 I/ActivityManager(880): Killing 31153:com.google.android.talk/u0a76 (adj 9): 63984k from cached
Hangouts gets killed and never receives the SMS broadcast, so the message never gets saved to the SMS content store and is lost forever (and the user gets no indication this is happening).
te...@gmail.com <te...@gmail.com> #16
If you decide to use the work around in https://code.google.com/p/android/issues/detail?id=53313#c1 above, be aware of a side effect I'm seeing with my application. The app switcher (task list) doesn't work properly. You application won't show up initially in the task list if you kill and then restart your application.
To duplicate issue:
- start then close your app (start your app, click app switcher button, swipe away/close your application)
- restart your app.
- click home button to return to home screen
- click app switcher button (notice that the button press registers, but nothing happens)
- click app switcher button again (the app switcher will display, but your application won't be visible)
- click app switcher button again (this will hide the app switcher)
- click app switcher button again (this will show the app switcher and you app will be visible now).
To duplicate issue:
- start then close your app (start your app, click app switcher button, swipe away/close your application)
- restart your app.
- click home button to return to home screen
- click app switcher button (notice that the button press registers, but nothing happens)
- click app switcher button again (the app switcher will display, but your application won't be visible)
- click app switcher button again (this will hide the app switcher)
- click app switcher button again (this will show the app switcher and you app will be visible now).
[Deleted User] <[Deleted User]> #17
I had the same problem developing a multimedia player service. The problem happened when I removed the task in a stopped or paused state but it worked in a playing state.
I think android tries to remove the service if the service isn't doing any usefull stuff. So I found a workaround just returning Service.START_NOT_STICKY in onStartCommand method in those states where the service is doing nothing special and Service.START_STICKY in other cases (like playing state).
I think android tries to remove the service if the service isn't doing any usefull stuff. So I found a workaround just returning Service.START_NOT_STICKY in onStartCommand method in those states where the service is doing nothing special and Service.START_STICKY in other cases (like playing state).
in...@issend.de <in...@issend.de> #18
Is this still open with Android 5.0/Lollipop, or has Google solved that issue?
[Deleted User] <[Deleted User]> #19
[Comment deleted]
ol...@gmail.com <ol...@gmail.com> #20
The issue remains in Android 5.0/Lollipop with Nexus 5
en...@google.com <en...@google.com>
[Deleted User] <[Deleted User]> #21
Why was this bug marked as obsolete? Can someone confirm this happens in android 5?
ol...@gmail.com <ol...@gmail.com> #22
I can no longer reproduce this on Android 5.0.1
in...@issend.de <in...@issend.de> #23
Yes, seems to be resolved on Android my Galaxy S5 with Android 5.0.
This device was also affected on KitKat.
This device was also affected on KitKat.
ra...@gmail.com <ra...@gmail.com> #24
Fixed at my nexus 5 with 5.0.1
m....@gmail.com <m....@gmail.com> #25
Does not seems to be fixed for me.
Nexus 4(Android 4.4.2), Nexus 4(Android 5.0), Nexus 5 and Nexus 6(both Android 5.0.1):
-start foreground Service
-close app via swipe in recent apps
-get a broadcast via GCM
-the foreground service dies
Log: Killing 27894:net.test.android.test/u0a20000: remove task
I had the same problem with some broadcasts I send via an other foreground service, and fixed it, by adding the Flag FLAG_RECEIVER_FOREGROUND to the intent, but i cant modifie the intent receiving via GCM.
At the time the Bug is limited on Nexus Devices for me, because I tested it on Galaxy S4 and HTC One and there is works fine.
Nexus 4(Android 4.4.2), Nexus 4(Android 5.0), Nexus 5 and Nexus 6(both Android 5.0.1):
-start foreground Service
-close app via swipe in recent apps
-get a broadcast via GCM
-the foreground service dies
Log: Killing 27894:net.test.android.test/u0a20000: remove task
I had the same problem with some broadcasts I send via an other foreground service, and fixed it, by adding the Flag FLAG_RECEIVER_FOREGROUND to the intent, but i cant modifie the intent receiving via GCM.
At the time the Bug is limited on Nexus Devices for me, because I tested it on Galaxy S4 and HTC One and there is works fine.
mh...@mhauge.dk <mh...@mhauge.dk> #26
Still a problem on my Nexus 4 - 5.1.1 official, cyanogenmod 12.1 and my Sony Xperia Z3 Compact 5.0.2 official
sa...@gmail.com <sa...@gmail.com> #27
I'm also getting this problem on:
1. My Sony Xperia M running Android 5.1.1 (Cyanogenmod 12.1)
2. Genymotion emulator running Android 4.4.4.
3. Genymotion emulator running Android 4.1.1
1. My Sony Xperia M running Android 5.1.1 (Cyanogenmod 12.1)
2. Genymotion emulator running Android 4.4.4.
3. Genymotion emulator running Android 4.1.1
sa...@gmail.com <sa...@gmail.com> #28
Note that my service and main activity are in separate processes, so the problem could be specific to that.
sa...@gmail.com <sa...@gmail.com> #29
sa...@gmail.com <sa...@gmail.com> #31
I should also say: it seems that it's important to unbind the service when your activity/UI isn't visible since being bound seems to increase the chances of this happening.
sa...@gmail.com <sa...@gmail.com> #32
I found one side effect of the DummyActivity workaround: it causes the "Recents" activity to disappear, so it alters the user experience.
sa...@gmail.com <sa...@gmail.com> #33
mh...@mhauge.dk <mh...@mhauge.dk> #34
#30 workaround is working for me.
lj...@gmail.com <lj...@gmail.com> #35
i found perfect workround
service killed because no activity in that process had binded it,i think it's a android bug.now you can do like below:
start an empty activity which run in service process, do bindservice then finish immediately.now your service process won't killed when user swipe away your app
class NannyActivity extends Activity {
public void onCreate(Bundle savedInstanceState) {
//must run in servce process,must bind that service
bindservice(xxxxx);
finish();
}
}
service killed because no activity in that process had binded it,i think it's a android bug.now you can do like below:
start an empty activity which run in service process, do bindservice then finish immediately.now your service process won't killed when user swipe away your app
class NannyActivity extends Activity {
public void onCreate(Bundle savedInstanceState) {
//must run in servce process,must bind that service
bindservice(xxxxx);
finish();
}
}
[Deleted User] <[Deleted User]> #36
It's not resolve in Lollipop. When I get gcm push message, my foreground service is killed! I'll try the workaround though.
[Deleted User] <[Deleted User]> #37
Verified #1 workaround. It's working!!! A million thanks!
Verified #36 workaround. Not working for me:-(
Verified #36 workaround. Not working for me:-(
mi...@naprvyraz.sk <mi...@naprvyraz.sk> #38
[Comment deleted]
mi...@naprvyraz.sk <mi...@naprvyraz.sk> #39
Definitely reproducible on Nexus/5.1.1.
#1's workaround is the only real fix here -- it removes the "waitingToKill=remove task" flag and accepts non-foreground intents.
#7's solution only fixes my own intents, i.e. those which are sent via PendingIntent from my own app. Any following intent without the foreground flag will again kill the service.
#1's workaround is the only real fix here -- it removes the "waitingToKill=remove task" flag and accepts non-foreground intents.
#7's solution only fixes my own intents, i.e. those which are sent via PendingIntent from my own app. Any following intent without the foreground flag will again kill the service.
s....@gmail.com <s....@gmail.com> #40
Well, there is almost 2016 year behind the door and I'm still encounter this issue on my Sony Xperia Z3 with Android 5.1.1. Was it closed or I'm still need to use those tricky workarounds to just play some background music?
jo...@visualblasters.com <jo...@visualblasters.com> #41
What an annoying issue. I'm seeing this issue on 4.2.2 and using emulator with 4.2. My details for reproducing it here:
http://stackoverflow.com/questions/29221149/foreground-service-getting-killed-when-pressing-home-button
I believe #3 is spot on what is going on and #1 workaround does not work.
GOOGLE/ANDROID TEAM please give us a potential official workaround/recommendations instead of leaving it as Obsolete! It's horrible how this happens with every single reported issues. The OS 4.2 is not obsolete and a large % are still running it! At the least tell us, no workaround possible.
I believe #3 is spot on what is going on and #1 workaround does not work.
GOOGLE/ANDROID TEAM please give us a potential official workaround/recommendations instead of leaving it as Obsolete! It's horrible how this happens with every single reported issues. The OS 4.2 is not obsolete and a large % are still running it! At the least tell us, no workaround possible.
m....@gmail.com <m....@gmail.com> #42
[Comment deleted]
m....@gmail.com <m....@gmail.com> #43
#1 and #36 didn't worked for me. But mixture of both somehow works.
The only problem is leaking ServiceConnection
public class MyBulletProofService extends Service {
private final IBinder mBinder = new LocalBinder();
/**
* Class used for the client Binder. Because we know this service always
* runs in the same process as its clients, we don't need to deal with IPC.
*/
public class LocalBinder extends Binder {
MyBulletProofService getService() {
// Return this instance of LocalService so clients can call public methods
return MyBulletProofService.this;
}
}
@Override
public IBinder onBind(Intent intent) {
return mBinder;
}
@Override
public void onTaskRemoved(Intent rootIntent) {
// start blank activity to prevent kill
// @seehttps://code.google.com/p/android/issues/detail?id=53313
Intent intent = new Intent(this, NannyActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
super.onTaskRemoved(rootIntent);
}
}
public class NannyActivity extends Activity {
private static final String TAG = "NannyActivity";
private ServiceConnection mConnection = new ServiceConnection() {
MyBulletProofService mService;
boolean mBound = false;
// Called when the connection with the service is established
public void onServiceConnected(ComponentName className, IBinder service) {
// Because we have bound to an explicit
// service that is running in our own process, we can
// cast its IBinder to a concrete class and directly access it.
// LocalBinder binder = (LocalBinder) service;
// mService = binder.getService();
mBound = true;
}
// Called when the connection with the service disconnects unexpectedly
public void onServiceDisconnected(ComponentName className) {
Log.e(TAG, "onServiceDisconnected");
mBound = false;
}
};
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//must run in service process,must bind that service
try {
Log.d(TAG, "NannyActivity binding to bg service");
Intent intent = new Intent(this, MyBulletProofService.class);
bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
} catch(ClassNotFoundException e) {
//noop
Log.d(TAG, "NannyActivity binding failed");
}
// finish();
}
}
// in AndroidManifest.xml
<activity
android:name=".NannyActivity"
android:theme="@android:style/Theme.NoDisplay"
android:enabled="true"
android:allowTaskReparenting="true"
android:noHistory="true"
android:excludeFromRecents="true"
android:alwaysRetainTaskState="false"
android:stateNotNeeded="true"
android:clearTaskOnLaunch="true"
android:finishOnTaskLaunch="true"
/>
The only problem is leaking ServiceConnection
public class MyBulletProofService extends Service {
private final IBinder mBinder = new LocalBinder();
/**
* Class used for the client Binder. Because we know this service always
* runs in the same process as its clients, we don't need to deal with IPC.
*/
public class LocalBinder extends Binder {
MyBulletProofService getService() {
// Return this instance of LocalService so clients can call public methods
return MyBulletProofService.this;
}
}
@Override
public IBinder onBind(Intent intent) {
return mBinder;
}
@Override
public void onTaskRemoved(Intent rootIntent) {
// start blank activity to prevent kill
// @see
Intent intent = new Intent(this, NannyActivity.class);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
startActivity(intent);
super.onTaskRemoved(rootIntent);
}
}
public class NannyActivity extends Activity {
private static final String TAG = "NannyActivity";
private ServiceConnection mConnection = new ServiceConnection() {
MyBulletProofService mService;
boolean mBound = false;
// Called when the connection with the service is established
public void onServiceConnected(ComponentName className, IBinder service) {
// Because we have bound to an explicit
// service that is running in our own process, we can
// cast its IBinder to a concrete class and directly access it.
// LocalBinder binder = (LocalBinder) service;
// mService = binder.getService();
mBound = true;
}
// Called when the connection with the service disconnects unexpectedly
public void onServiceDisconnected(ComponentName className) {
Log.e(TAG, "onServiceDisconnected");
mBound = false;
}
};
public void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
//must run in service process,must bind that service
try {
Log.d(TAG, "NannyActivity binding to bg service");
Intent intent = new Intent(this, MyBulletProofService.class);
bindService(intent, mConnection, Context.BIND_AUTO_CREATE);
} catch(ClassNotFoundException e) {
//noop
Log.d(TAG, "NannyActivity binding failed");
}
// finish();
}
}
// in AndroidManifest.xml
<activity
android:name=".NannyActivity"
android:theme="@android:style/Theme.NoDisplay"
android:enabled="true"
android:allowTaskReparenting="true"
android:noHistory="true"
android:excludeFromRecents="true"
android:alwaysRetainTaskState="false"
android:stateNotNeeded="true"
android:clearTaskOnLaunch="true"
android:finishOnTaskLaunch="true"
/>
so...@gmail.com <so...@gmail.com> #44
Happens on my LG G4 (LGE LG-H815 Android 6.0) and on LGE Nexus 5 (Android 6.0.1)
ar...@gmail.com <ar...@gmail.com> #45
#44 is not working on Le Eco Max 2, 6.0.1
br...@abax.no <br...@abax.no> #46
I had the same issue (Foreground start and is killed), when the I launch a foreground service from a BroadcastReceiver, this case triggered by an alarm.
I tried few ways, but one seemed simple. From Broadcast, start an IntentService, onHandleIntent(), startService(ForegroundIntent).
(The app that holds the foreground should be whiteListed)
Working at Huawei P9 EMUI 4.1.1 Android 6.0.1
I tried few ways, but one seemed simple. From Broadcast, start an IntentService, onHandleIntent(), startService(ForegroundIntent).
(The app that holds the foreground should be whiteListed)
Working at Huawei P9 EMUI 4.1.1 Android 6.0.1
dc...@gmail.com <dc...@gmail.com> #47
Re #47: could you please be clearer? The process you describe seems to be a pretty straightforward one where you launch an IntentService that goes into foreground. I have issues with a Huawei P9 which kills the service 10 seconds after turning off the screen
sa...@gmail.com <sa...@gmail.com> #48
ka...@gmail.com <ka...@gmail.com> #49
No internet my youtube vanced
Description
- Start a foreground service from an activity
- Exit the activity via Home
- Swipe the app away in the Recent Apps list
- At some later time (could be 10 seconds later), send the foreground service a broadcast it listens for
(in my case, from an AccessibilityService)
* What happened.
Foreground service is killed. Immediately after the broadcast is sent, log shows:
W/KeyguardViewMediator(14677): verifyUnlock called when not externally disabled
I/ActivityManager(14677): Killing 31586:net.dinglisch.android.tasker/u0a10002: remove task
W/ActivityManager(14677): Scheduling restart of crashed service net.dinglisch.android.tasker/.MonitorService in 5000ms
W/ActivityManager(14677): Scheduling restart of crashed service net.dinglisch.android.tasker/.MyAccessibilityService in 15000ms
MonitorService is the foreground service. MyAccessibilityService is the broadcast-sending service.
- What you think the correct behavior should be
Foreground service should not be killed.
Users report the problem on many JB versions, from 4.1.1 to 4.2.2.
Dev forum thread:
Pent