Foreground service START_STICKY is not restarted after being killed in low memory conditions
I know there are tones of threads with similar title, but no one of them gives a definitive answer.
We're currently stress testing the foreground service of our application by filling up the RAM with junk with another app and investigating what happens to our application and its foreground service.
So, our foreground service is started and notification is shown to the user, and its mode is START_STICKY. However, when we simulate extreme memory usage the application is killed (which is OK and we can do nothing about it), but the bad thing is that our foreground service never gets restarted. Perhaps I'm confusing something from the START_STICKY doc, but what I can understand from below doc is that system should guarantee the restart, isn't it?
Constant to return from
onStartCommand(Intent, int, int): if this
service's process is killed while it is started (after returning from
onStartCommand(Intent, int, int)), then leave it in the started state
but don't retain this delivered intent. Later the system will try to
re-create the service. Because it is in the started state, it will
guarantee to callonStartCommand(Intent, int, int)after creating the
new service instance; if there are not any pending start commands to
be delivered to the service, it will be called with a null intent
object, so you must take care to check for this.
The above doc is too vague.
First question is
- will it ALWAYS RESTART the service? If not, what are the
conditions for the service being restarted and what are the
conditions when it won't be restarted?
And the second question is
- What does it mean Later? Later when? Later next year or what? :D
To summarize, we do need to guarantee that our foreground service will restart whatever it takes. Any ideas?
EDIT 1:
I did investigate the logcat logs a little bit more. Here's is what happens.
Process com.MY_PACKAGE_ID (pid 1192) has died: prcp FGS
Scheduling restart of crashed service com.MY_PACKAGE_ID/MyForegroundService in 1284608ms
Obviously, the system kills the application and schedules a restart. In this case it's approximately in 21 minutes. In other cases I would see that the reschedule time was 10.000ms aka 10 seconds. And, in 10 seconds the device would still be in memory stressful situation and the app will not be launched. Which implies, that in case the service fails to start at rescheduled time there won't be any 2nd rescheduling and the service will never restart. But, if at rescheduled time the device was in normal non-memory stressful conditions, the restart will happen successfully.
android service asked Nov 12 at 11:37
kyurkchyan
1,09021229
add a comment |
I know there are tones of threads with similar title, but no one of them gives a definitive answer.
We're currently stress testing the foreground service of our application by filling up the RAM with junk with another app and investigating what happens to our application and its foreground service.
So, our foreground service is started and notification is shown to the user, and its mode is START_STICKY. However, when we simulate extreme memory usage the application is killed (which is OK and we can do nothing about it), but the bad thing is that our foreground service never gets restarted. Perhaps I'm confusing something from the START_STICKY doc, but what I can understand from below doc is that system should guarantee the restart, isn't it?
Constant to return from
onStartCommand(Intent, int, int): if this
service's process is killed while it is started (after returning from
onStartCommand(Intent, int, int)), then leave it in the started state
but don't retain this delivered intent. Later the system will try to
re-create the service. Because it is in the started state, it will
guarantee to callonStartCommand(Intent, int, int)after creating the
new service instance; if there are not any pending start commands to
be delivered to the service, it will be called with a null intent
object, so you must take care to check for this.
The above doc is too vague.
First question is
- will it ALWAYS RESTART the service? If not, what are the
conditions for the service being restarted and what are the
conditions when it won't be restarted?
And the second question is
- What does it mean Later? Later when? Later next year or what? :D
To summarize, we do need to guarantee that our foreground service will restart whatever it takes. Any ideas?
EDIT 1:
I did investigate the logcat logs a little bit more. Here's is what happens.
Process com.MY_PACKAGE_ID (pid 1192) has died: prcp FGS
Scheduling restart of crashed service com.MY_PACKAGE_ID/MyForegroundService in 1284608ms
Obviously, the system kills the application and schedules a restart. In this case it's approximately in 21 minutes. In other cases I would see that the reschedule time was 10.000ms aka 10 seconds. And, in 10 seconds the device would still be in memory stressful situation and the app will not be launched. Which implies, that in case the service fails to start at rescheduled time there won't be any 2nd rescheduling and the service will never restart. But, if at rescheduled time the device was in normal non-memory stressful conditions, the restart will happen successfully.
android service asked Nov 12 at 11:37
kyurkchyan
1,09021229
In my experience, "later" means from 0 to infinity. There are no guarantees. If the system elected to end a foreground service, things must've gotten pretty bad, so consider this: What guarantee is there that more resources will ever become available? And, what if another app on the system is trying to do the same thing you're doing? (How does the system know which of the two apps is more important?) These are unanswered questions. If you really want this functionality, I would suggest a custom ROM.
– greeble31
Nov 13 at 20:54
@greeble31 thanks for the reply. Yeah, indeed it might mean from 0 to infinity. I had the same thoughts as you...
– kyurkchyan
Nov 14 at 5:50
add a comment |
I know there are tones of threads with similar title, but no one of them gives a definitive answer.
We're currently stress testing the foreground service of our application by filling up the RAM with junk with another app and investigating what happens to our application and its foreground service.
So, our foreground service is started and notification is shown to the user, and its mode is START_STICKY. However, when we simulate extreme memory usage the application is killed (which is OK and we can do nothing about it), but the bad thing is that our foreground service never gets restarted. Perhaps I'm confusing something from the START_STICKY doc, but what I can understand from below doc is that system should guarantee the restart, isn't it?
Constant to return from
onStartCommand(Intent, int, int): if this
service's process is killed while it is started (after returning from
onStartCommand(Intent, int, int)), then leave it in the started state
but don't retain this delivered intent. Later the system will try to
re-create the service. Because it is in the started state, it will
guarantee to callonStartCommand(Intent, int, int)after creating the
new service instance; if there are not any pending start commands to
be delivered to the service, it will be called with a null intent
object, so you must take care to check for this.
The above doc is too vague.
First question is
- will it ALWAYS RESTART the service? If not, what are the
conditions for the service being restarted and what are the
conditions when it won't be restarted?
And the second question is
- What does it mean Later? Later when? Later next year or what? :D
To summarize, we do need to guarantee that our foreground service will restart whatever it takes. Any ideas?
EDIT 1:
I did investigate the logcat logs a little bit more. Here's is what happens.
Process com.MY_PACKAGE_ID (pid 1192) has died: prcp FGS
Scheduling restart of crashed service com.MY_PACKAGE_ID/MyForegroundService in 1284608ms
Obviously, the system kills the application and schedules a restart. In this case it's approximately in 21 minutes. In other cases I would see that the reschedule time was 10.000ms aka 10 seconds. And, in 10 seconds the device would still be in memory stressful situation and the app will not be launched. Which implies, that in case the service fails to start at rescheduled time there won't be any 2nd rescheduling and the service will never restart. But, if at rescheduled time the device was in normal non-memory stressful conditions, the restart will happen successfully.
android service asked Nov 12 at 11:37
kyurkchyan
1,09021229
I know there are tones of threads with similar title, but no one of them gives a definitive answer.
We're currently stress testing the foreground service of our application by filling up the RAM with junk with another app and investigating what happens to our application and its foreground service.
So, our foreground service is started and notification is shown to the user, and its mode is START_STICKY. However, when we simulate extreme memory usage the application is killed (which is OK and we can do nothing about it), but the bad thing is that our foreground service never gets restarted. Perhaps I'm confusing something from the START_STICKY doc, but what I can understand from below doc is that system should guarantee the restart, isn't it?
Constant to return from
onStartCommand(Intent, int, int): if this
service's process is killed while it is started (after returning from
onStartCommand(Intent, int, int)), then leave it in the started state
but don't retain this delivered intent. Later the system will try to
re-create the service. Because it is in the started state, it will
guarantee to callonStartCommand(Intent, int, int)after creating the
new service instance; if there are not any pending start commands to
be delivered to the service, it will be called with a null intent
object, so you must take care to check for this.
The above doc is too vague.
First question is
- will it ALWAYS RESTART the service? If not, what are the
conditions for the service being restarted and what are the
conditions when it won't be restarted?
And the second question is
- What does it mean Later? Later when? Later next year or what? :D
To summarize, we do need to guarantee that our foreground service will restart whatever it takes. Any ideas?
EDIT 1:
I did investigate the logcat logs a little bit more. Here's is what happens.
Process com.MY_PACKAGE_ID (pid 1192) has died: prcp FGS
Scheduling restart of crashed service com.MY_PACKAGE_ID/MyForegroundService in 1284608ms
Obviously, the system kills the application and schedules a restart. In this case it's approximately in 21 minutes. In other cases I would see that the reschedule time was 10.000ms aka 10 seconds. And, in 10 seconds the device would still be in memory stressful situation and the app will not be launched. Which implies, that in case the service fails to start at rescheduled time there won't be any 2nd rescheduling and the service will never restart. But, if at rescheduled time the device was in normal non-memory stressful conditions, the restart will happen successfully.
android service android service asked Nov 12 at 11:37
kyurkchyan
1,09021229
asked Nov 12 at 11:37
kyurkchyan
1,09021229
edited Nov 14 at 9:57
asked Nov 12 at 11:37
kyurkchyan
1,09021229
asked Nov 12 at 11:37
kyurkchyan
1,09021229
asked Nov 12 at 11:37
kyurkchyan
1,09021229
1,09021229
In my experience, "later" means from 0 to infinity. There are no guarantees. If the system elected to end a foreground service, things must've gotten pretty bad, so consider this: What guarantee is there that more resources will ever become available? And, what if another app on the system is trying to do the same thing you're doing? (How does the system know which of the two apps is more important?) These are unanswered questions. If you really want this functionality, I would suggest a custom ROM.
– greeble31
Nov 13 at 20:54
@greeble31 thanks for the reply. Yeah, indeed it might mean from 0 to infinity. I had the same thoughts as you...
– kyurkchyan
Nov 14 at 5:50
add a comment |
In my experience, "later" means from 0 to infinity. There are no guarantees. If the system elected to end a foreground service, things must've gotten pretty bad, so consider this: What guarantee is there that more resources will ever become available? And, what if another app on the system is trying to do the same thing you're doing? (How does the system know which of the two apps is more important?) These are unanswered questions. If you really want this functionality, I would suggest a custom ROM.
– greeble31
Nov 13 at 20:54
@greeble31 thanks for the reply. Yeah, indeed it might mean from 0 to infinity. I had the same thoughts as you...
– kyurkchyan
Nov 14 at 5:50
In my experience, "later" means from 0 to infinity. There are no guarantees. If the system elected to end a foreground service, things must've gotten pretty bad, so consider this: What guarantee is there that more resources will ever become available? And, what if another app on the system is trying to do the same thing you're doing? (How does the system know which of the two apps is more important?) These are unanswered questions. If you really want this functionality, I would suggest a custom ROM.
– greeble31
Nov 13 at 20:54
In my experience, "later" means from 0 to infinity. There are no guarantees. If the system elected to end a foreground service, things must've gotten pretty bad, so consider this: What guarantee is there that more resources will ever become available? And, what if another app on the system is trying to do the same thing you're doing? (How does the system know which of the two apps is more important?) These are unanswered questions. If you really want this functionality, I would suggest a custom ROM.
– greeble31
Nov 13 at 20:54
@greeble31 thanks for the reply. Yeah, indeed it might mean from 0 to infinity. I had the same thoughts as you...
– kyurkchyan
Nov 14 at 5:50
@greeble31 thanks for the reply. Yeah, indeed it might mean from 0 to infinity. I had the same thoughts as you...
– kyurkchyan
Nov 14 at 5:50
add a comment |
active
oldest
votes
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53261349%2fforeground-service-start-sticky-is-not-restarted-after-being-killed-in-low-memor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
active
oldest
votes
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53261349%2fforeground-service-start-sticky-is-not-restarted-after-being-killed-in-low-memor%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
In my experience, "later" means from 0 to infinity. There are no guarantees. If the system elected to end a foreground service, things must've gotten pretty bad, so consider this: What guarantee is there that more resources will ever become available? And, what if another app on the system is trying to do the same thing you're doing? (How does the system know which of the two apps is more important?) These are unanswered questions. If you really want this functionality, I would suggest a custom ROM.
– greeble31
Nov 13 at 20:54
@greeble31 thanks for the reply. Yeah, indeed it might mean from 0 to infinity. I had the same thoughts as you...
– kyurkchyan
Nov 14 at 5:50