Mixing
How can I cause the Android Application class to be recreated?
Application class: Sometimes it's recreated
Tell me if I have this right: When starting an Android application, if there's a class that extends android.app.Application, that class will be created when the application starts. But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again. So if there are any instance variables that were initialized before, those variables are no longer set.
Testing robustness of recreation of the Application instance
This question is about how to test to see how well an application survives the process of having it's application class recreated.
I have found that I can go into an activity in my application, then switch to other applications for "a long time" (on the order of hours), and when I come back I see that the constructor runs in my class that extends android.app.Application. The problem is that I don't know how to force this recreation so that I can test efficiently.
Restarting from various activities
I'm adding this paragraph to the original question to call attention to the testing I'd like to undertake. I'd like to expand upon above, where I said "...go to an activity in my application, then switch (away from my application)...". The idea is NOT to kill the whole application and start 'from the top'. The user is inside an activity that, if the Application instance survives, might behave one way, but if the Application instance happens to be recreated, then might behave another way.
I'm not asking for the following problem to be solved in this question (it's covered elsewhere). I am asking for a process whereby problems like this can be uncovered in testing. So the example: let's say that an instance variable is saved in the Application instance when the initial activity runs. Classes that need that variable can get it from the Application instance, but only if the initial activity has set it already. Now the OS decides to wipe-out and recreate the Application instance. When the user brings the app to the foreground, and they're running some random activity (never going through the onCreate() of the initial activity), the instance variable is null. If the activity is well-coded, it will not just crash with an NPE. So I'm trying to test to make sure that in the above situation, where the instance variable is null, that the app behaves nicely. I THINK I've got it, but I'd like to make sure, and I'd like to make sure no matter what activity is running when the user puts their phone down.
What the log looks like
If the application is left at one of the child activities and application is put in the background for a "long time", the OS destroys some class instances. When the application gets focus again, there are some creation processes. Here is what the log looks like.
I/zygote: Late-enabling -Xcheck:jni
V/DaleApplication: DaleApplication constructor.
I/InstantRun: starting instant run server: is main process
V/DaleApplication: DaleApplication onCreate.
V/DaleDatabaseAdapter: constructor.
V/DaleListActivity: onCreate() is pulling records from the database.
V/DaleListActivity: >>>>>> Selection Args T
You can see I put logging into DaleApplication which extends android.app.Application. As an aside, we also see it also recreates the database adapter and starts pulling records from the database, putting the user right back where they were before all these objects were destroyed.
The answer I'm seeking in this question would be some process that I could undertake that would allow me to cause the class instance destruction on demand, thus allowing me to validate that the rebuilding process is sound.
What I've Tried
Although I figured that killing the whole application would not work, an answer below suggested I try it. But of course I need the activity that the user was using at the time the phone was set down to resume.
1) I tried kill via adb:
After getting my adb.exe command line working, I was able to get the pid for my app using adb shell, then pidof ..(aid).., where ..(aid).. is the ApplicationId in build.gradle. That returned 13488.
I tried to kill the application using am kill ..(aid).., but that said nothing, and the pid was still there. I tried kill 13488 but that said Operation not permitted. With a -9 didn't help.
EDIT: I finally got this method to work after finally straightening out which instance of adb.exe to interact with. It was equivalent to pressing the 'Terminate App' button [see item "3)", below].
2) I tried hitting the "red square" in debug tool window:
In the debug tool window, I selected "Threads". There were a bunch of things in there. I had no idea which thread to stop that would emulate the user putting their phone down for an hour. After stopping main, when I went back to the application on my phone, the application started the main activity (not like when just the Application class gets recreated, which starts whatever child activity was running earlier).
EDIT: I think this is not a good approach, but there might some thread here that doesn't cause Android to start the previous activity instead of the last activity. Did not investigate more because this answer solved the problem for me.
3) Terminate App button in Logcat:
I was able press the 'home' button on the phone, then hit the "red square" in the logcat window, but that put me at the activity before the activity I was on when I pressed the home button.
From what I understand when you terminate the app from Android Studio (logcat), Android presumes that the current activity is not well-behaved, so instead of starting it, it starts the previous activity. This doesn't match the behavior of when the phone is set aside for a long time and then the app is restored to the foreground.
android android-lifecycle android-instant-run asked Dec 31 '18 at 18:28
DaleDale
1,67512445
add a comment |
Application class: Sometimes it's recreated
Tell me if I have this right: When starting an Android application, if there's a class that extends android.app.Application, that class will be created when the application starts. But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again. So if there are any instance variables that were initialized before, those variables are no longer set.
Testing robustness of recreation of the Application instance
This question is about how to test to see how well an application survives the process of having it's application class recreated.
I have found that I can go into an activity in my application, then switch to other applications for "a long time" (on the order of hours), and when I come back I see that the constructor runs in my class that extends android.app.Application. The problem is that I don't know how to force this recreation so that I can test efficiently.
Restarting from various activities
I'm adding this paragraph to the original question to call attention to the testing I'd like to undertake. I'd like to expand upon above, where I said "...go to an activity in my application, then switch (away from my application)...". The idea is NOT to kill the whole application and start 'from the top'. The user is inside an activity that, if the Application instance survives, might behave one way, but if the Application instance happens to be recreated, then might behave another way.
I'm not asking for the following problem to be solved in this question (it's covered elsewhere). I am asking for a process whereby problems like this can be uncovered in testing. So the example: let's say that an instance variable is saved in the Application instance when the initial activity runs. Classes that need that variable can get it from the Application instance, but only if the initial activity has set it already. Now the OS decides to wipe-out and recreate the Application instance. When the user brings the app to the foreground, and they're running some random activity (never going through the onCreate() of the initial activity), the instance variable is null. If the activity is well-coded, it will not just crash with an NPE. So I'm trying to test to make sure that in the above situation, where the instance variable is null, that the app behaves nicely. I THINK I've got it, but I'd like to make sure, and I'd like to make sure no matter what activity is running when the user puts their phone down.
What the log looks like
If the application is left at one of the child activities and application is put in the background for a "long time", the OS destroys some class instances. When the application gets focus again, there are some creation processes. Here is what the log looks like.
I/zygote: Late-enabling -Xcheck:jni
V/DaleApplication: DaleApplication constructor.
I/InstantRun: starting instant run server: is main process
V/DaleApplication: DaleApplication onCreate.
V/DaleDatabaseAdapter: constructor.
V/DaleListActivity: onCreate() is pulling records from the database.
V/DaleListActivity: >>>>>> Selection Args T
You can see I put logging into DaleApplication which extends android.app.Application. As an aside, we also see it also recreates the database adapter and starts pulling records from the database, putting the user right back where they were before all these objects were destroyed.
The answer I'm seeking in this question would be some process that I could undertake that would allow me to cause the class instance destruction on demand, thus allowing me to validate that the rebuilding process is sound.
What I've Tried
Although I figured that killing the whole application would not work, an answer below suggested I try it. But of course I need the activity that the user was using at the time the phone was set down to resume.
1) I tried kill via adb:
After getting my adb.exe command line working, I was able to get the pid for my app using adb shell, then pidof ..(aid).., where ..(aid).. is the ApplicationId in build.gradle. That returned 13488.
I tried to kill the application using am kill ..(aid).., but that said nothing, and the pid was still there. I tried kill 13488 but that said Operation not permitted. With a -9 didn't help.
EDIT: I finally got this method to work after finally straightening out which instance of adb.exe to interact with. It was equivalent to pressing the 'Terminate App' button [see item "3)", below].
2) I tried hitting the "red square" in debug tool window:
In the debug tool window, I selected "Threads". There were a bunch of things in there. I had no idea which thread to stop that would emulate the user putting their phone down for an hour. After stopping main, when I went back to the application on my phone, the application started the main activity (not like when just the Application class gets recreated, which starts whatever child activity was running earlier).
EDIT: I think this is not a good approach, but there might some thread here that doesn't cause Android to start the previous activity instead of the last activity. Did not investigate more because this answer solved the problem for me.
3) Terminate App button in Logcat:
I was able press the 'home' button on the phone, then hit the "red square" in the logcat window, but that put me at the activity before the activity I was on when I pressed the home button.
From what I understand when you terminate the app from Android Studio (logcat), Android presumes that the current activity is not well-behaved, so instead of starting it, it starts the previous activity. This doesn't match the behavior of when the phone is set aside for a long time and then the app is restored to the foreground.
android android-lifecycle android-instant-run asked Dec 31 '18 at 18:28
DaleDale
1,67512445
add a comment |
Application class: Sometimes it's recreated
Tell me if I have this right: When starting an Android application, if there's a class that extends android.app.Application, that class will be created when the application starts. But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again. So if there are any instance variables that were initialized before, those variables are no longer set.
Testing robustness of recreation of the Application instance
This question is about how to test to see how well an application survives the process of having it's application class recreated.
I have found that I can go into an activity in my application, then switch to other applications for "a long time" (on the order of hours), and when I come back I see that the constructor runs in my class that extends android.app.Application. The problem is that I don't know how to force this recreation so that I can test efficiently.
Restarting from various activities
I'm adding this paragraph to the original question to call attention to the testing I'd like to undertake. I'd like to expand upon above, where I said "...go to an activity in my application, then switch (away from my application)...". The idea is NOT to kill the whole application and start 'from the top'. The user is inside an activity that, if the Application instance survives, might behave one way, but if the Application instance happens to be recreated, then might behave another way.
I'm not asking for the following problem to be solved in this question (it's covered elsewhere). I am asking for a process whereby problems like this can be uncovered in testing. So the example: let's say that an instance variable is saved in the Application instance when the initial activity runs. Classes that need that variable can get it from the Application instance, but only if the initial activity has set it already. Now the OS decides to wipe-out and recreate the Application instance. When the user brings the app to the foreground, and they're running some random activity (never going through the onCreate() of the initial activity), the instance variable is null. If the activity is well-coded, it will not just crash with an NPE. So I'm trying to test to make sure that in the above situation, where the instance variable is null, that the app behaves nicely. I THINK I've got it, but I'd like to make sure, and I'd like to make sure no matter what activity is running when the user puts their phone down.
What the log looks like
If the application is left at one of the child activities and application is put in the background for a "long time", the OS destroys some class instances. When the application gets focus again, there are some creation processes. Here is what the log looks like.
I/zygote: Late-enabling -Xcheck:jni
V/DaleApplication: DaleApplication constructor.
I/InstantRun: starting instant run server: is main process
V/DaleApplication: DaleApplication onCreate.
V/DaleDatabaseAdapter: constructor.
V/DaleListActivity: onCreate() is pulling records from the database.
V/DaleListActivity: >>>>>> Selection Args T
You can see I put logging into DaleApplication which extends android.app.Application. As an aside, we also see it also recreates the database adapter and starts pulling records from the database, putting the user right back where they were before all these objects were destroyed.
The answer I'm seeking in this question would be some process that I could undertake that would allow me to cause the class instance destruction on demand, thus allowing me to validate that the rebuilding process is sound.
What I've Tried
Although I figured that killing the whole application would not work, an answer below suggested I try it. But of course I need the activity that the user was using at the time the phone was set down to resume.
1) I tried kill via adb:
After getting my adb.exe command line working, I was able to get the pid for my app using adb shell, then pidof ..(aid).., where ..(aid).. is the ApplicationId in build.gradle. That returned 13488.
I tried to kill the application using am kill ..(aid).., but that said nothing, and the pid was still there. I tried kill 13488 but that said Operation not permitted. With a -9 didn't help.
EDIT: I finally got this method to work after finally straightening out which instance of adb.exe to interact with. It was equivalent to pressing the 'Terminate App' button [see item "3)", below].
2) I tried hitting the "red square" in debug tool window:
In the debug tool window, I selected "Threads". There were a bunch of things in there. I had no idea which thread to stop that would emulate the user putting their phone down for an hour. After stopping main, when I went back to the application on my phone, the application started the main activity (not like when just the Application class gets recreated, which starts whatever child activity was running earlier).
EDIT: I think this is not a good approach, but there might some thread here that doesn't cause Android to start the previous activity instead of the last activity. Did not investigate more because this answer solved the problem for me.
3) Terminate App button in Logcat:
I was able press the 'home' button on the phone, then hit the "red square" in the logcat window, but that put me at the activity before the activity I was on when I pressed the home button.
From what I understand when you terminate the app from Android Studio (logcat), Android presumes that the current activity is not well-behaved, so instead of starting it, it starts the previous activity. This doesn't match the behavior of when the phone is set aside for a long time and then the app is restored to the foreground.
android android-lifecycle android-instant-run asked Dec 31 '18 at 18:28
DaleDale
1,67512445
Application class: Sometimes it's recreated
Tell me if I have this right: When starting an Android application, if there's a class that extends android.app.Application, that class will be created when the application starts. But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again. So if there are any instance variables that were initialized before, those variables are no longer set.
Testing robustness of recreation of the Application instance
This question is about how to test to see how well an application survives the process of having it's application class recreated.
I have found that I can go into an activity in my application, then switch to other applications for "a long time" (on the order of hours), and when I come back I see that the constructor runs in my class that extends android.app.Application. The problem is that I don't know how to force this recreation so that I can test efficiently.
Restarting from various activities
I'm adding this paragraph to the original question to call attention to the testing I'd like to undertake. I'd like to expand upon above, where I said "...go to an activity in my application, then switch (away from my application)...". The idea is NOT to kill the whole application and start 'from the top'. The user is inside an activity that, if the Application instance survives, might behave one way, but if the Application instance happens to be recreated, then might behave another way.
I'm not asking for the following problem to be solved in this question (it's covered elsewhere). I am asking for a process whereby problems like this can be uncovered in testing. So the example: let's say that an instance variable is saved in the Application instance when the initial activity runs. Classes that need that variable can get it from the Application instance, but only if the initial activity has set it already. Now the OS decides to wipe-out and recreate the Application instance. When the user brings the app to the foreground, and they're running some random activity (never going through the onCreate() of the initial activity), the instance variable is null. If the activity is well-coded, it will not just crash with an NPE. So I'm trying to test to make sure that in the above situation, where the instance variable is null, that the app behaves nicely. I THINK I've got it, but I'd like to make sure, and I'd like to make sure no matter what activity is running when the user puts their phone down.
What the log looks like
If the application is left at one of the child activities and application is put in the background for a "long time", the OS destroys some class instances. When the application gets focus again, there are some creation processes. Here is what the log looks like.
I/zygote: Late-enabling -Xcheck:jni
V/DaleApplication: DaleApplication constructor.
I/InstantRun: starting instant run server: is main process
V/DaleApplication: DaleApplication onCreate.
V/DaleDatabaseAdapter: constructor.
V/DaleListActivity: onCreate() is pulling records from the database.
V/DaleListActivity: >>>>>> Selection Args T
You can see I put logging into DaleApplication which extends android.app.Application. As an aside, we also see it also recreates the database adapter and starts pulling records from the database, putting the user right back where they were before all these objects were destroyed.
The answer I'm seeking in this question would be some process that I could undertake that would allow me to cause the class instance destruction on demand, thus allowing me to validate that the rebuilding process is sound.
What I've Tried
Although I figured that killing the whole application would not work, an answer below suggested I try it. But of course I need the activity that the user was using at the time the phone was set down to resume.
1) I tried kill via adb:
After getting my adb.exe command line working, I was able to get the pid for my app using adb shell, then pidof ..(aid).., where ..(aid).. is the ApplicationId in build.gradle. That returned 13488.
I tried to kill the application using am kill ..(aid).., but that said nothing, and the pid was still there. I tried kill 13488 but that said Operation not permitted. With a -9 didn't help.
EDIT: I finally got this method to work after finally straightening out which instance of adb.exe to interact with. It was equivalent to pressing the 'Terminate App' button [see item "3)", below].
2) I tried hitting the "red square" in debug tool window:
In the debug tool window, I selected "Threads". There were a bunch of things in there. I had no idea which thread to stop that would emulate the user putting their phone down for an hour. After stopping main, when I went back to the application on my phone, the application started the main activity (not like when just the Application class gets recreated, which starts whatever child activity was running earlier).
EDIT: I think this is not a good approach, but there might some thread here that doesn't cause Android to start the previous activity instead of the last activity. Did not investigate more because this answer solved the problem for me.
3) Terminate App button in Logcat:
I was able press the 'home' button on the phone, then hit the "red square" in the logcat window, but that put me at the activity before the activity I was on when I pressed the home button.
From what I understand when you terminate the app from Android Studio (logcat), Android presumes that the current activity is not well-behaved, so instead of starting it, it starts the previous activity. This doesn't match the behavior of when the phone is set aside for a long time and then the app is restored to the foreground.
android android-lifecycle android-instant-run android android-lifecycle android-instant-run asked Dec 31 '18 at 18:28
DaleDale
1,67512445
asked Dec 31 '18 at 18:28
DaleDale
1,67512445
edited Jan 2 at 16:47
Dale
asked Dec 31 '18 at 18:28
DaleDale
1,67512445
asked Dec 31 '18 at 18:28
DaleDale
1,67512445
asked Dec 31 '18 at 18:28
DaleDale
1,67512445
1,67512445
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
When starting an Android application, if there's a class that extends android.app.Application, that class will be created when the application starts
More accurately, an instance of that class will be created when your process is created.
But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again.
More accurately, your process can be terminated at any time when your app is not in the foreground (and, on rare occasion, even when it is in the foreground). All of your objects, including the Application singleton, go away when your process does. Your next process will have its own Application singleton.
So if there are any instance variables that were initialized before, those variables are no longer set.
That depends a lot on when they get initialized. For example, if you initialize them in onCreate(), they will be initialized again in new instances of your Application subclass.
How can I cause the Android Application class to be recreated?
Terminate the process. In Android Studio, the red square "stop" toolbar button does this. You can also terminate the process from the command line. In many cases, swiping your task off of the overview screen will terminate your process.
answered Dec 31 '18 at 18:37
CommonsWareCommonsWare
778k13918961942
Thanks for the more appropriate wording. I've added a paragraph to expand on the question because it wasn't clear enough that in order to test the "missing" instance variables in theApplicationinstance, we need to keep running the activity that the user is doing when they set down their phone.
– Dale
Dec 31 '18 at 20:05
@Dale: "Classes that need that variable can get it from the Application instance, but only if the initial activity has set it already" -- that is a major code smell. I would focus first on getting rid of that pattern. To test process termination without getting rid of the task, from the command line, useadb shell am kill ..., where...is replaced by yourapplicationId.
– CommonsWare
Dec 31 '18 at 20:25
Thanks again. And you are correct and wise about the smell, but that's a problem for a different day. I tried theadb ... kill, which ran without error, but I didn't seeApplication.onTerminate()run, nor did I see the constructor orApplication.onCreate()run when I started using the app again (I pulled the instance variable from the child activity and it was already initialized). So that's not emulating what I see when the app leaves foreground for 'a long time'.
– Dale
Dec 31 '18 at 21:04
@Dale: "I didn't see Application.onTerminate() run" -- that will never be called. "nor did I see the constructor or Application.onCreate() run when I started using the app again" -- perhaps you used the wrongapplicationId. You can useadb shell psto confirm that your application's process was terminated.
– CommonsWare
Dec 31 '18 at 21:13
I'm using adb.exe incorrectly; I've been running a second instance. All I see inadb shell psis thepsitself. I went toTerminalwindow, thencdto...HTC Sync. The kill command takes any applicationId and doesn't call BS. The applicationId I used was the one inbuild.gradle. Sorry if pumping commands into the 'real' adb is a noob mistake...I've never done it.
– Dale
Dec 31 '18 at 21:31
|
show 1 more comment
1.) Put the app in background with HOME button
2.) Terminate the app from Android Studio
3.) Restart the app from the LAUNCHER on the device
Enjoy!
But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again.
Actually, that has nothing to do with "not being used", the whole process is being terminated by Android.
You can persist things across process death with onSaveInstanceState(Bundle), then restore it in void onCreate(Bundle savedInstanceState) where savedInstanceState != null.
answered Jan 2 at 0:57
EpicPandaForceEpicPandaForce
50.2k15133264
This does not put me at the activity that was running when the home button was pressed. It puts me at the activity before that, so does not solve the question.
– Dale
Jan 2 at 1:00
It can only put you "before that" if the activity you are talking about hasandroid:noHistory="true"flag set, which is out of scope from my perspective as I've never had a use for it.
– EpicPandaForce
Jan 2 at 1:01
Killing it this way causes Android to "think" that the current activity is not well behaved, so starts the previous activity. Nothing to do with setting any history flags.
– Dale
Jan 2 at 1:14
It's only "not well behaved" if the task is restored and your Activity crashes for whatever reason (possibly NPE) :P I've done this 100+ times it works just fine.
– EpicPandaForce
Jan 2 at 2:50
We are back to the purpose of the question: A way to PROVE that the application is "well behaved" by starting the activity that was running when the app went into the background. I've proven to myself by removing the interaction with the savedInstanceState that clicking theTerminate Applicationbutton does not test the activity where as stackoverflow.com/a/54000145/897007 does.
– Dale
Jan 2 at 16:22
add a comment |
The easiest way to test your application to see if it survives well when the OS removes things is to configure your testing device to not save things in the first place. This way, every time you hit the home button the OS will not save anything.
If you go into Settings > System > Developer Options > Apps, you should see:
Don't keep activities <<< Turn this on
Background process limit <<< Set this to 'No background processes'
answered Jan 2 at 0:55
DaleDale
1,67512445
don't keep activitiesnever happens in real life, except if it's set in the developer options - it certainly does not simulate process death. I don't think Background process limit works properly on Android P, or at least it definitely didn't trigger process death when I expected it.
– EpicPandaForce
Jan 2 at 0:58
I've seen the logs from my application when the OS naturally removes things (see the original question), and I've seen the logs when developer options are set this way. The logs are the same in both cases with respect to constructors andonCreate()calls. So we'll need to disagree.
– Dale
Jan 2 at 1:03
The real question is if you are testing on Android P, too.
– EpicPandaForce
Jan 2 at 1:12
add a comment |
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%2f53990402%2fhow-can-i-cause-the-android-application-class-to-be-recreated%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
When starting an Android application, if there's a class that extends android.app.Application, that class will be created when the application starts
More accurately, an instance of that class will be created when your process is created.
But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again.
More accurately, your process can be terminated at any time when your app is not in the foreground (and, on rare occasion, even when it is in the foreground). All of your objects, including the Application singleton, go away when your process does. Your next process will have its own Application singleton.
So if there are any instance variables that were initialized before, those variables are no longer set.
That depends a lot on when they get initialized. For example, if you initialize them in onCreate(), they will be initialized again in new instances of your Application subclass.
How can I cause the Android Application class to be recreated?
Terminate the process. In Android Studio, the red square "stop" toolbar button does this. You can also terminate the process from the command line. In many cases, swiping your task off of the overview screen will terminate your process.
answered Dec 31 '18 at 18:37
CommonsWareCommonsWare
778k13918961942
Thanks for the more appropriate wording. I've added a paragraph to expand on the question because it wasn't clear enough that in order to test the "missing" instance variables in theApplicationinstance, we need to keep running the activity that the user is doing when they set down their phone.
– Dale
Dec 31 '18 at 20:05
@Dale: "Classes that need that variable can get it from the Application instance, but only if the initial activity has set it already" -- that is a major code smell. I would focus first on getting rid of that pattern. To test process termination without getting rid of the task, from the command line, useadb shell am kill ..., where...is replaced by yourapplicationId.
– CommonsWare
Dec 31 '18 at 20:25
Thanks again. And you are correct and wise about the smell, but that's a problem for a different day. I tried theadb ... kill, which ran without error, but I didn't seeApplication.onTerminate()run, nor did I see the constructor orApplication.onCreate()run when I started using the app again (I pulled the instance variable from the child activity and it was already initialized). So that's not emulating what I see when the app leaves foreground for 'a long time'.
– Dale
Dec 31 '18 at 21:04
@Dale: "I didn't see Application.onTerminate() run" -- that will never be called. "nor did I see the constructor or Application.onCreate() run when I started using the app again" -- perhaps you used the wrongapplicationId. You can useadb shell psto confirm that your application's process was terminated.
– CommonsWare
Dec 31 '18 at 21:13
I'm using adb.exe incorrectly; I've been running a second instance. All I see inadb shell psis thepsitself. I went toTerminalwindow, thencdto...HTC Sync. The kill command takes any applicationId and doesn't call BS. The applicationId I used was the one inbuild.gradle. Sorry if pumping commands into the 'real' adb is a noob mistake...I've never done it.
– Dale
Dec 31 '18 at 21:31
|
show 1 more comment
When starting an Android application, if there's a class that extends android.app.Application, that class will be created when the application starts
More accurately, an instance of that class will be created when your process is created.
But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again.
More accurately, your process can be terminated at any time when your app is not in the foreground (and, on rare occasion, even when it is in the foreground). All of your objects, including the Application singleton, go away when your process does. Your next process will have its own Application singleton.
So if there are any instance variables that were initialized before, those variables are no longer set.
That depends a lot on when they get initialized. For example, if you initialize them in onCreate(), they will be initialized again in new instances of your Application subclass.
How can I cause the Android Application class to be recreated?
Terminate the process. In Android Studio, the red square "stop" toolbar button does this. You can also terminate the process from the command line. In many cases, swiping your task off of the overview screen will terminate your process.
answered Dec 31 '18 at 18:37
CommonsWareCommonsWare
778k13918961942
Thanks for the more appropriate wording. I've added a paragraph to expand on the question because it wasn't clear enough that in order to test the "missing" instance variables in theApplicationinstance, we need to keep running the activity that the user is doing when they set down their phone.
– Dale
Dec 31 '18 at 20:05
@Dale: "Classes that need that variable can get it from the Application instance, but only if the initial activity has set it already" -- that is a major code smell. I would focus first on getting rid of that pattern. To test process termination without getting rid of the task, from the command line, useadb shell am kill ..., where...is replaced by yourapplicationId.
– CommonsWare
Dec 31 '18 at 20:25
Thanks again. And you are correct and wise about the smell, but that's a problem for a different day. I tried theadb ... kill, which ran without error, but I didn't seeApplication.onTerminate()run, nor did I see the constructor orApplication.onCreate()run when I started using the app again (I pulled the instance variable from the child activity and it was already initialized). So that's not emulating what I see when the app leaves foreground for 'a long time'.
– Dale
Dec 31 '18 at 21:04
@Dale: "I didn't see Application.onTerminate() run" -- that will never be called. "nor did I see the constructor or Application.onCreate() run when I started using the app again" -- perhaps you used the wrongapplicationId. You can useadb shell psto confirm that your application's process was terminated.
– CommonsWare
Dec 31 '18 at 21:13
I'm using adb.exe incorrectly; I've been running a second instance. All I see inadb shell psis thepsitself. I went toTerminalwindow, thencdto...HTC Sync. The kill command takes any applicationId and doesn't call BS. The applicationId I used was the one inbuild.gradle. Sorry if pumping commands into the 'real' adb is a noob mistake...I've never done it.
– Dale
Dec 31 '18 at 21:31
|
show 1 more comment
When starting an Android application, if there's a class that extends android.app.Application, that class will be created when the application starts
More accurately, an instance of that class will be created when your process is created.
But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again.
More accurately, your process can be terminated at any time when your app is not in the foreground (and, on rare occasion, even when it is in the foreground). All of your objects, including the Application singleton, go away when your process does. Your next process will have its own Application singleton.
So if there are any instance variables that were initialized before, those variables are no longer set.
That depends a lot on when they get initialized. For example, if you initialize them in onCreate(), they will be initialized again in new instances of your Application subclass.
How can I cause the Android Application class to be recreated?
Terminate the process. In Android Studio, the red square "stop" toolbar button does this. You can also terminate the process from the command line. In many cases, swiping your task off of the overview screen will terminate your process.
answered Dec 31 '18 at 18:37
CommonsWareCommonsWare
778k13918961942
When starting an Android application, if there's a class that extends android.app.Application, that class will be created when the application starts
More accurately, an instance of that class will be created when your process is created.
But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again.
More accurately, your process can be terminated at any time when your app is not in the foreground (and, on rare occasion, even when it is in the foreground). All of your objects, including the Application singleton, go away when your process does. Your next process will have its own Application singleton.
So if there are any instance variables that were initialized before, those variables are no longer set.
That depends a lot on when they get initialized. For example, if you initialize them in onCreate(), they will be initialized again in new instances of your Application subclass.
How can I cause the Android Application class to be recreated?
Terminate the process. In Android Studio, the red square "stop" toolbar button does this. You can also terminate the process from the command line. In many cases, swiping your task off of the overview screen will terminate your process.
answered Dec 31 '18 at 18:37
CommonsWareCommonsWare
778k13918961942
answered Dec 31 '18 at 18:37
CommonsWareCommonsWare
778k13918961942
answered Dec 31 '18 at 18:37
CommonsWareCommonsWare
778k13918961942
answered Dec 31 '18 at 18:37
CommonsWareCommonsWare
778k13918961942
778k13918961942
Thanks for the more appropriate wording. I've added a paragraph to expand on the question because it wasn't clear enough that in order to test the "missing" instance variables in theApplicationinstance, we need to keep running the activity that the user is doing when they set down their phone.
– Dale
Dec 31 '18 at 20:05
@Dale: "Classes that need that variable can get it from the Application instance, but only if the initial activity has set it already" -- that is a major code smell. I would focus first on getting rid of that pattern. To test process termination without getting rid of the task, from the command line, useadb shell am kill ..., where...is replaced by yourapplicationId.
– CommonsWare
Dec 31 '18 at 20:25
Thanks again. And you are correct and wise about the smell, but that's a problem for a different day. I tried theadb ... kill, which ran without error, but I didn't seeApplication.onTerminate()run, nor did I see the constructor orApplication.onCreate()run when I started using the app again (I pulled the instance variable from the child activity and it was already initialized). So that's not emulating what I see when the app leaves foreground for 'a long time'.
– Dale
Dec 31 '18 at 21:04
@Dale: "I didn't see Application.onTerminate() run" -- that will never be called. "nor did I see the constructor or Application.onCreate() run when I started using the app again" -- perhaps you used the wrongapplicationId. You can useadb shell psto confirm that your application's process was terminated.
– CommonsWare
Dec 31 '18 at 21:13
I'm using adb.exe incorrectly; I've been running a second instance. All I see inadb shell psis thepsitself. I went toTerminalwindow, thencdto...HTC Sync. The kill command takes any applicationId and doesn't call BS. The applicationId I used was the one inbuild.gradle. Sorry if pumping commands into the 'real' adb is a noob mistake...I've never done it.
– Dale
Dec 31 '18 at 21:31
|
show 1 more comment
Thanks for the more appropriate wording. I've added a paragraph to expand on the question because it wasn't clear enough that in order to test the "missing" instance variables in theApplicationinstance, we need to keep running the activity that the user is doing when they set down their phone.
– Dale
Dec 31 '18 at 20:05
@Dale: "Classes that need that variable can get it from the Application instance, but only if the initial activity has set it already" -- that is a major code smell. I would focus first on getting rid of that pattern. To test process termination without getting rid of the task, from the command line, useadb shell am kill ..., where...is replaced by yourapplicationId.
– CommonsWare
Dec 31 '18 at 20:25
Thanks again. And you are correct and wise about the smell, but that's a problem for a different day. I tried theadb ... kill, which ran without error, but I didn't seeApplication.onTerminate()run, nor did I see the constructor orApplication.onCreate()run when I started using the app again (I pulled the instance variable from the child activity and it was already initialized). So that's not emulating what I see when the app leaves foreground for 'a long time'.
– Dale
Dec 31 '18 at 21:04
@Dale: "I didn't see Application.onTerminate() run" -- that will never be called. "nor did I see the constructor or Application.onCreate() run when I started using the app again" -- perhaps you used the wrongapplicationId. You can useadb shell psto confirm that your application's process was terminated.
– CommonsWare
Dec 31 '18 at 21:13
I'm using adb.exe incorrectly; I've been running a second instance. All I see inadb shell psis thepsitself. I went toTerminalwindow, thencdto...HTC Sync. The kill command takes any applicationId and doesn't call BS. The applicationId I used was the one inbuild.gradle. Sorry if pumping commands into the 'real' adb is a noob mistake...I've never done it.
– Dale
Dec 31 '18 at 21:31
Thanks for the more appropriate wording. I've added a paragraph to expand on the question because it wasn't clear enough that in order to test the "missing" instance variables in the
Application instance, we need to keep running the activity that the user is doing when they set down their phone.– Dale
Dec 31 '18 at 20:05
Thanks for the more appropriate wording. I've added a paragraph to expand on the question because it wasn't clear enough that in order to test the "missing" instance variables in the
Application instance, we need to keep running the activity that the user is doing when they set down their phone.– Dale
Dec 31 '18 at 20:05
@Dale: "Classes that need that variable can get it from the Application instance, but only if the initial activity has set it already" -- that is a major code smell. I would focus first on getting rid of that pattern. To test process termination without getting rid of the task, from the command line, use
adb shell am kill ..., where ... is replaced by your applicationId.– CommonsWare
Dec 31 '18 at 20:25
@Dale: "Classes that need that variable can get it from the Application instance, but only if the initial activity has set it already" -- that is a major code smell. I would focus first on getting rid of that pattern. To test process termination without getting rid of the task, from the command line, use
adb shell am kill ..., where ... is replaced by your applicationId.– CommonsWare
Dec 31 '18 at 20:25
Thanks again. And you are correct and wise about the smell, but that's a problem for a different day. I tried the
adb ... kill, which ran without error, but I didn't see Application.onTerminate() run, nor did I see the constructor or Application.onCreate() run when I started using the app again (I pulled the instance variable from the child activity and it was already initialized). So that's not emulating what I see when the app leaves foreground for 'a long time'.– Dale
Dec 31 '18 at 21:04
Thanks again. And you are correct and wise about the smell, but that's a problem for a different day. I tried the
adb ... kill, which ran without error, but I didn't see Application.onTerminate() run, nor did I see the constructor or Application.onCreate() run when I started using the app again (I pulled the instance variable from the child activity and it was already initialized). So that's not emulating what I see when the app leaves foreground for 'a long time'.– Dale
Dec 31 '18 at 21:04
@Dale: "I didn't see Application.onTerminate() run" -- that will never be called. "nor did I see the constructor or Application.onCreate() run when I started using the app again" -- perhaps you used the wrong
applicationId. You can use adb shell ps to confirm that your application's process was terminated.– CommonsWare
Dec 31 '18 at 21:13
@Dale: "I didn't see Application.onTerminate() run" -- that will never be called. "nor did I see the constructor or Application.onCreate() run when I started using the app again" -- perhaps you used the wrong
applicationId. You can use adb shell ps to confirm that your application's process was terminated.– CommonsWare
Dec 31 '18 at 21:13
I'm using adb.exe incorrectly; I've been running a second instance. All I see in
adb shell ps is the ps itself. I went to Terminal window, then cd to ...HTC Sync. The kill command takes any applicationId and doesn't call BS. The applicationId I used was the one in build.gradle. Sorry if pumping commands into the 'real' adb is a noob mistake...I've never done it.– Dale
Dec 31 '18 at 21:31
I'm using adb.exe incorrectly; I've been running a second instance. All I see in
adb shell ps is the ps itself. I went to Terminal window, then cd to ...HTC Sync. The kill command takes any applicationId and doesn't call BS. The applicationId I used was the one in build.gradle. Sorry if pumping commands into the 'real' adb is a noob mistake...I've never done it.– Dale
Dec 31 '18 at 21:31
|
show 1 more comment
1.) Put the app in background with HOME button
2.) Terminate the app from Android Studio
3.) Restart the app from the LAUNCHER on the device
Enjoy!
But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again.
Actually, that has nothing to do with "not being used", the whole process is being terminated by Android.
You can persist things across process death with onSaveInstanceState(Bundle), then restore it in void onCreate(Bundle savedInstanceState) where savedInstanceState != null.
answered Jan 2 at 0:57
EpicPandaForceEpicPandaForce
50.2k15133264
This does not put me at the activity that was running when the home button was pressed. It puts me at the activity before that, so does not solve the question.
– Dale
Jan 2 at 1:00
It can only put you "before that" if the activity you are talking about hasandroid:noHistory="true"flag set, which is out of scope from my perspective as I've never had a use for it.
– EpicPandaForce
Jan 2 at 1:01
Killing it this way causes Android to "think" that the current activity is not well behaved, so starts the previous activity. Nothing to do with setting any history flags.
– Dale
Jan 2 at 1:14
It's only "not well behaved" if the task is restored and your Activity crashes for whatever reason (possibly NPE) :P I've done this 100+ times it works just fine.
– EpicPandaForce
Jan 2 at 2:50
We are back to the purpose of the question: A way to PROVE that the application is "well behaved" by starting the activity that was running when the app went into the background. I've proven to myself by removing the interaction with the savedInstanceState that clicking theTerminate Applicationbutton does not test the activity where as stackoverflow.com/a/54000145/897007 does.
– Dale
Jan 2 at 16:22
add a comment |
1.) Put the app in background with HOME button
2.) Terminate the app from Android Studio
3.) Restart the app from the LAUNCHER on the device
Enjoy!
But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again.
Actually, that has nothing to do with "not being used", the whole process is being terminated by Android.
You can persist things across process death with onSaveInstanceState(Bundle), then restore it in void onCreate(Bundle savedInstanceState) where savedInstanceState != null.
answered Jan 2 at 0:57
EpicPandaForceEpicPandaForce
50.2k15133264
This does not put me at the activity that was running when the home button was pressed. It puts me at the activity before that, so does not solve the question.
– Dale
Jan 2 at 1:00
It can only put you "before that" if the activity you are talking about hasandroid:noHistory="true"flag set, which is out of scope from my perspective as I've never had a use for it.
– EpicPandaForce
Jan 2 at 1:01
Killing it this way causes Android to "think" that the current activity is not well behaved, so starts the previous activity. Nothing to do with setting any history flags.
– Dale
Jan 2 at 1:14
It's only "not well behaved" if the task is restored and your Activity crashes for whatever reason (possibly NPE) :P I've done this 100+ times it works just fine.
– EpicPandaForce
Jan 2 at 2:50
We are back to the purpose of the question: A way to PROVE that the application is "well behaved" by starting the activity that was running when the app went into the background. I've proven to myself by removing the interaction with the savedInstanceState that clicking theTerminate Applicationbutton does not test the activity where as stackoverflow.com/a/54000145/897007 does.
– Dale
Jan 2 at 16:22
add a comment |
1.) Put the app in background with HOME button
2.) Terminate the app from Android Studio
3.) Restart the app from the LAUNCHER on the device
Enjoy!
But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again.
Actually, that has nothing to do with "not being used", the whole process is being terminated by Android.
You can persist things across process death with onSaveInstanceState(Bundle), then restore it in void onCreate(Bundle savedInstanceState) where savedInstanceState != null.
answered Jan 2 at 0:57
EpicPandaForceEpicPandaForce
50.2k15133264
1.) Put the app in background with HOME button
2.) Terminate the app from Android Studio
3.) Restart the app from the LAUNCHER on the device
Enjoy!
But if the application is not being used, then that instance may be deleted and later recreated when the application comes to the foreground again.
Actually, that has nothing to do with "not being used", the whole process is being terminated by Android.
You can persist things across process death with onSaveInstanceState(Bundle), then restore it in void onCreate(Bundle savedInstanceState) where savedInstanceState != null.
answered Jan 2 at 0:57
EpicPandaForceEpicPandaForce
50.2k15133264
answered Jan 2 at 0:57
EpicPandaForceEpicPandaForce
50.2k15133264
answered Jan 2 at 0:57
EpicPandaForceEpicPandaForce
50.2k15133264
answered Jan 2 at 0:57
EpicPandaForceEpicPandaForce
50.2k15133264
50.2k15133264
This does not put me at the activity that was running when the home button was pressed. It puts me at the activity before that, so does not solve the question.
– Dale
Jan 2 at 1:00
It can only put you "before that" if the activity you are talking about hasandroid:noHistory="true"flag set, which is out of scope from my perspective as I've never had a use for it.
– EpicPandaForce
Jan 2 at 1:01
Killing it this way causes Android to "think" that the current activity is not well behaved, so starts the previous activity. Nothing to do with setting any history flags.
– Dale
Jan 2 at 1:14
It's only "not well behaved" if the task is restored and your Activity crashes for whatever reason (possibly NPE) :P I've done this 100+ times it works just fine.
– EpicPandaForce
Jan 2 at 2:50
We are back to the purpose of the question: A way to PROVE that the application is "well behaved" by starting the activity that was running when the app went into the background. I've proven to myself by removing the interaction with the savedInstanceState that clicking theTerminate Applicationbutton does not test the activity where as stackoverflow.com/a/54000145/897007 does.
– Dale
Jan 2 at 16:22
add a comment |
This does not put me at the activity that was running when the home button was pressed. It puts me at the activity before that, so does not solve the question.
– Dale
Jan 2 at 1:00
It can only put you "before that" if the activity you are talking about hasandroid:noHistory="true"flag set, which is out of scope from my perspective as I've never had a use for it.
– EpicPandaForce
Jan 2 at 1:01
Killing it this way causes Android to "think" that the current activity is not well behaved, so starts the previous activity. Nothing to do with setting any history flags.
– Dale
Jan 2 at 1:14
It's only "not well behaved" if the task is restored and your Activity crashes for whatever reason (possibly NPE) :P I've done this 100+ times it works just fine.
– EpicPandaForce
Jan 2 at 2:50
We are back to the purpose of the question: A way to PROVE that the application is "well behaved" by starting the activity that was running when the app went into the background. I've proven to myself by removing the interaction with the savedInstanceState that clicking theTerminate Applicationbutton does not test the activity where as stackoverflow.com/a/54000145/897007 does.
– Dale
Jan 2 at 16:22
This does not put me at the activity that was running when the home button was pressed. It puts me at the activity before that, so does not solve the question.
– Dale
Jan 2 at 1:00
This does not put me at the activity that was running when the home button was pressed. It puts me at the activity before that, so does not solve the question.
– Dale
Jan 2 at 1:00
It can only put you "before that" if the activity you are talking about has
android:noHistory="true" flag set, which is out of scope from my perspective as I've never had a use for it.– EpicPandaForce
Jan 2 at 1:01
It can only put you "before that" if the activity you are talking about has
android:noHistory="true" flag set, which is out of scope from my perspective as I've never had a use for it.– EpicPandaForce
Jan 2 at 1:01
Killing it this way causes Android to "think" that the current activity is not well behaved, so starts the previous activity. Nothing to do with setting any history flags.
– Dale
Jan 2 at 1:14
Killing it this way causes Android to "think" that the current activity is not well behaved, so starts the previous activity. Nothing to do with setting any history flags.
– Dale
Jan 2 at 1:14
It's only "not well behaved" if the task is restored and your Activity crashes for whatever reason (possibly NPE) :P I've done this 100+ times it works just fine.
– EpicPandaForce
Jan 2 at 2:50
It's only "not well behaved" if the task is restored and your Activity crashes for whatever reason (possibly NPE) :P I've done this 100+ times it works just fine.
– EpicPandaForce
Jan 2 at 2:50
We are back to the purpose of the question: A way to PROVE that the application is "well behaved" by starting the activity that was running when the app went into the background. I've proven to myself by removing the interaction with the savedInstanceState that clicking the
Terminate Application button does not test the activity where as stackoverflow.com/a/54000145/897007 does.– Dale
Jan 2 at 16:22
We are back to the purpose of the question: A way to PROVE that the application is "well behaved" by starting the activity that was running when the app went into the background. I've proven to myself by removing the interaction with the savedInstanceState that clicking the
Terminate Application button does not test the activity where as stackoverflow.com/a/54000145/897007 does.– Dale
Jan 2 at 16:22
add a comment |
The easiest way to test your application to see if it survives well when the OS removes things is to configure your testing device to not save things in the first place. This way, every time you hit the home button the OS will not save anything.
If you go into Settings > System > Developer Options > Apps, you should see:
Don't keep activities <<< Turn this on
Background process limit <<< Set this to 'No background processes'
answered Jan 2 at 0:55
DaleDale
1,67512445
don't keep activitiesnever happens in real life, except if it's set in the developer options - it certainly does not simulate process death. I don't think Background process limit works properly on Android P, or at least it definitely didn't trigger process death when I expected it.
– EpicPandaForce
Jan 2 at 0:58
I've seen the logs from my application when the OS naturally removes things (see the original question), and I've seen the logs when developer options are set this way. The logs are the same in both cases with respect to constructors andonCreate()calls. So we'll need to disagree.
– Dale
Jan 2 at 1:03
The real question is if you are testing on Android P, too.
– EpicPandaForce
Jan 2 at 1:12
add a comment |
The easiest way to test your application to see if it survives well when the OS removes things is to configure your testing device to not save things in the first place. This way, every time you hit the home button the OS will not save anything.
If you go into Settings > System > Developer Options > Apps, you should see:
Don't keep activities <<< Turn this on
Background process limit <<< Set this to 'No background processes'
answered Jan 2 at 0:55
DaleDale
1,67512445
don't keep activitiesnever happens in real life, except if it's set in the developer options - it certainly does not simulate process death. I don't think Background process limit works properly on Android P, or at least it definitely didn't trigger process death when I expected it.
– EpicPandaForce
Jan 2 at 0:58
I've seen the logs from my application when the OS naturally removes things (see the original question), and I've seen the logs when developer options are set this way. The logs are the same in both cases with respect to constructors andonCreate()calls. So we'll need to disagree.
– Dale
Jan 2 at 1:03
The real question is if you are testing on Android P, too.
– EpicPandaForce
Jan 2 at 1:12
add a comment |
The easiest way to test your application to see if it survives well when the OS removes things is to configure your testing device to not save things in the first place. This way, every time you hit the home button the OS will not save anything.
If you go into Settings > System > Developer Options > Apps, you should see:
Don't keep activities <<< Turn this on
Background process limit <<< Set this to 'No background processes'
answered Jan 2 at 0:55
DaleDale
1,67512445
The easiest way to test your application to see if it survives well when the OS removes things is to configure your testing device to not save things in the first place. This way, every time you hit the home button the OS will not save anything.
If you go into Settings > System > Developer Options > Apps, you should see:
Don't keep activities <<< Turn this on
Background process limit <<< Set this to 'No background processes'
answered Jan 2 at 0:55
DaleDale
1,67512445
answered Jan 2 at 0:55
DaleDale
1,67512445
answered Jan 2 at 0:55
DaleDale
1,67512445
answered Jan 2 at 0:55
DaleDale
1,67512445
1,67512445
don't keep activitiesnever happens in real life, except if it's set in the developer options - it certainly does not simulate process death. I don't think Background process limit works properly on Android P, or at least it definitely didn't trigger process death when I expected it.
– EpicPandaForce
Jan 2 at 0:58
I've seen the logs from my application when the OS naturally removes things (see the original question), and I've seen the logs when developer options are set this way. The logs are the same in both cases with respect to constructors andonCreate()calls. So we'll need to disagree.
– Dale
Jan 2 at 1:03
The real question is if you are testing on Android P, too.
– EpicPandaForce
Jan 2 at 1:12
add a comment |
don't keep activitiesnever happens in real life, except if it's set in the developer options - it certainly does not simulate process death. I don't think Background process limit works properly on Android P, or at least it definitely didn't trigger process death when I expected it.
– EpicPandaForce
Jan 2 at 0:58
I've seen the logs from my application when the OS naturally removes things (see the original question), and I've seen the logs when developer options are set this way. The logs are the same in both cases with respect to constructors andonCreate()calls. So we'll need to disagree.
– Dale
Jan 2 at 1:03
The real question is if you are testing on Android P, too.
– EpicPandaForce
Jan 2 at 1:12
don't keep activities never happens in real life, except if it's set in the developer options - it certainly does not simulate process death. I don't think Background process limit works properly on Android P, or at least it definitely didn't trigger process death when I expected it.– EpicPandaForce
Jan 2 at 0:58
don't keep activities never happens in real life, except if it's set in the developer options - it certainly does not simulate process death. I don't think Background process limit works properly on Android P, or at least it definitely didn't trigger process death when I expected it.– EpicPandaForce
Jan 2 at 0:58
I've seen the logs from my application when the OS naturally removes things (see the original question), and I've seen the logs when developer options are set this way. The logs are the same in both cases with respect to constructors and
onCreate() calls. So we'll need to disagree.– Dale
Jan 2 at 1:03
I've seen the logs from my application when the OS naturally removes things (see the original question), and I've seen the logs when developer options are set this way. The logs are the same in both cases with respect to constructors and
onCreate() calls. So we'll need to disagree.– Dale
Jan 2 at 1:03
The real question is if you are testing on Android P, too.
– EpicPandaForce
Jan 2 at 1:12
The real question is if you are testing on Android P, too.
– EpicPandaForce
Jan 2 at 1:12
add a comment |
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.
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%2f53990402%2fhow-can-i-cause-the-android-application-class-to-be-recreated%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
