In my app I have a simple button that launches a second activity, starts a spinner (If that's relevant) and does some http connection work. This second activity can also be launched by a service that runs and listens to a bluetooth connection.
The problem is not happening on my milestone (2.1-update1) phone but on a colleagues phone who is running 2.3 I believe. When they press the button to launch the second activity (Ignoring the service portion completely) it will launch the activity multiple times, when they press back on that second screen they land on another instance of that second screen instead of being back on the first activity.
I mention the service part of this for two reason, the first being that this problem started happening when I implemented the service, and the second being because I had a separate problem where the clients weren't being managed correctly on the service side so that when the second activity was being launched through the service instead of the button I would see exactly this behavior. Since the message was being sent to all clients (There should only be one) I was seeing the service spawn multiple launches of this second activity. But again by pressing the button this service problem which has been fixed shouldn't be responsible.
Now, I have put two things in place to prevent this from happening anymore. I have flagged the second activity as singleTask (android:launchMode="singleTask") and noticed that I had been launching the second activity as startActivityForResult, but wasn't setting or using that when it came back. This wasn't causing any errors or anything, but I changed it to a plain startActivity.
I do not have physical access to the other phone so I can't hook it up to logcat or anything, as it is in another office elsewhere.
The other phone isn't seeing the problem anymore but I am worried that I have hidden the problem rather than really fixing it, and was wondering if anyone could provide some insight?
I've had a problem before where different phones exhibited different symptoms when starting services. Some would restart (kill and start) the service multiple times and others would not. I'm taking a guess that because your friend's phone restarts the service multiple times somehow your activity is getting called each time it restarts.
Try this, can you show notifications in your service? If so do:
startForeground(ID_NOTIFICATION, notification);
This makes the service always run in the foreground and it is less likely to be killed by android.
Related
In my app I have two activities, A and B. A downloads some data and starts activity B when the data is downloaded - this is done through a BroadcastReceiver whose onReceive() method starts B through an intent.
My problem is that, when I my app goes to background while the data is still downloading (e.g. I start my app, then quickly click the "home" button, or switch app with the square "switch" button), my app comes back to foreground once the data is downloaded... annoying.
So far I've tried adding flags and setting actions on the intent to avoid that, including intent.setAction(Intent.ACTION_SCREEN_ON), which might be close to the answer: it works nicely on a device running API 16 but not on mine which is running API 22.
Typically, one uses a service to carry out operations in the background. Services don't have a UI (for obvious reasons). By definition, an Activity is a foreground task - the behavior you're seeing is exactly what is supposed to happen.
I'd strongly suggest NOT trying to turn an activity into a service. You'd be working against the whole application life cycle when you could use a feature in Android designed for the very purpose you seek.
Here's a quick resource, I suggest you read more on services:
https://developer.android.com/training/best-background.html
The BroadcastReceiver for an Activity receives and processes Intent objects even when your app is in the background, but doesn't force your app to the foreground. If you want to notify the user about an event that happened in the background while your app was not visible, use a Notification. Never start an Activity in response to an incoming broadcast Intent.
My Android app checks if a specific service is not running, in my Activity's onResume method. If it hasn't been started, then it goes into the background (via startService) and stays there for an action. Clicking on a button causes the service to go into the foreground and it works great. Now the problem:
Scenario #1 :
The foreground service has a button, which sends it back to the background and stops it. I click on it and after that I close my app (the activities from the recents view). Even the Android monitor shows me that it's not running and works as it should.
Scenario #2: (The not expected behavior)
First I close the app (the activities) and then I click on the service's close button. In this case, I can clearly see that my app still uses the same amount of memory it used while the activities were opened. When I reopen my app, I can see that it continues working where I left it (at least the internal app variables don't get garbage collected) Sometimes the CPU usage monitor shows that methods get called, but not from my app. Only Android SDK functions. I couldn't see objects kept in the memory, but a lot of chat[], String, FinalizerReferences etc...
What could cause this? Ruined context lifecycle? Memory leak?
First sorry for my english.
I have a problem, and i can't find a solution, it sounds like:
i'm developping an app that's getting my location from gps and send it to a tcp server on pc , and store the data into a listview (for example). I have set a timer that send the location every 2 seconds. Everything works fine even if i connect two clients to server, until the phones gets locked .. then my server receive ugly string ..it seems like the sent-strings it straddles (the string contains parts of data from bought clients, parts are concatenated) .. but when i unlock the phones the server receive normal strings again..
I want to know how to make my app run in the same parameters when lock screen occurs .. Any ideas?
If you are doing this inside an activity or a fragment you are probably having an issue with the lifecycle of your app. If you want to understand the lifecycle, read this documentation article: http://developer.android.com/training/basics/activity-lifecycle/index.html
Doing nothing on your onPause method won't prevent your activity from sleeping, Android can kill your activity anytime.
The proper way to do this would be inside a Service, a service is a special component on Android that is executed independently of what the user is doing or not doing, and in this case, you could create a service that holds a wake lock in order to prevent it from sleeping for the couple of seconds you need to send your data.
An easier solution would be to use something like this Location polling library and suit it to your needs.
When the screen locks your activity is either paused on stopped and it is important you handle these methods so that any interuptions are handled elegantly and without error. Or so the app will continue to run in the background.
If you read up about the activity lifecycle.
During normal app use, the foreground activity is sometimes obstructed by other visual components that cause the activity to pause. For example, when a semi-transparent activity opens (such as one in the style of a dialog), the previous activity pauses. As long as the activity is still partially visible but currently not the activity in focus, it remains paused.
However, once the activity is fully-obstructed and not visible, it stops (which is discussed in the next lesson).
Activity Lifecycle from android.com
I've done a fair bit of searching for my issue, but can't find any solutions to my exact problem.
I have an app that has 3 activities in succession. The main activity (on launch), the second activity (where most of the meat and guts live), and then a final activity that is more or less a summary page of what happens in the 2nd activity.
I run into this issue semi-sporadically where if I keep the 2nd activity running in the background (turn the screen of my phone off, or just hit home) and then hit the launcher icon to go back to the app, it creates a new instance instead of returning to my 2nd activity that is running in the background. I can't find any rhyme or reason as to why it happens sometimes and not others (usually it doesn't). Most of the time it takes me right back to my 2nd activity and all is good in the world, but on occasion, it fires up another instance.
Is there anyway to check if an instance is running and ALWAYS return to that instance if there is?
When you hit Home or the screen turns off, the app automatically goes through the onStop() phase. Depending upon the available memory, the app might become a candidate to be killed by the Android OS. There really is no way to prevent the OS from killing an app that is no longer in the foreground - this is an Android OS design. This should most likely not happen if you do not have a lot of applications open.
If the first instance of the app is still around and you launch the app, it will automatically retrieve this instance. Android is designed to never create a second instance of the same app while the first one is still running. Hence there is no way to check is an instance is running. You could use logging inside onDestroy() to see when the app terminates. But again, Android does not always call onDestroy() and might just simply terminate the app.
I have an offline-online application, i found a strange issue in it, may be it is not, but i did'nt understand about it..
App requirement is that, if internet is available, even from starting app or from resuming, i call webservices and store data in sqlite, otherwise app stays in offline mode,
I have 2 activities, second activity contains an id, that i passes through intent (that point is important),
My Problem:
if i am in second activity, and internet is running, and i press home button , then this 2nd activity pauses, then stop which is a default behavior in android, i goto settings, turn wifi off, then press app icon again to get back in my app, here i got confused, i expect that my app now will be in onResume, but when i see in logcat its onCreated called and app
crashes, nullPointerException occurs, because this 2nd activity does not have that id, i passed through intent..
Note:
If i use recent app button to go to "settings", then come back again after turing wifi off, and repeat all this behavior, then working fine, its onResumes called not oncreate..
My Question
Why it is going in onCreate while i my expectation is to be onResume while i came back from app icon?
The NPE reason is clear, your second activity doesn't have the value and it crashes.
Why do you get different behavior then!?
It's because the launching intents are different. When you "task switch" Android is merely stopping your app but leaving it there (no guarantee) in case you want to switch back.
Going home (with home) is a clear indication that you want to leave the app, and although it will remain in memory and cached (as long as there is available memory), going back through the launcher (or App Icon as you call it) fires the LAUNCHER category (which goes to your Activity 1 first).
Take a look at this StackOverflow question (and answer) to better understand the consequences.
In any case, your problem is that your app must always be designed to resume in an inconsistent state and be able to recover. Android will kill your references, will destroy your variables and most likely send your app to hell overnight even if you have it running… if the phone goes on standby, chances are processes that aren't doing anything will be paused/stopped and likely killed.
Re-design your app so this is not a problem.
You say:
"I have 2 activities, second activity contains an id, that i passes
through intent (that point is important),"
Well, why not make it easier and have ONE activity and TWO fragments? Then use Fragment Arguments to pass the value?
Or why not store the value in the preferences and/or a local database and recover it during onCreate?
And also why not make it so that if Activity 2 doesn't have a value, it calls Activity 1 and closes itself (better than a crash, huh?).
Etc.
As you can see there are multiple things you should consider. All in all, never trust that your app will be alive, because it won't.
Once your activity's onStop gets called it's susceptible to be killed by the android system to collect resources for other apps which is what i think happened in your case.If it is killed, android will obviously call OnCreate when you get back to the activity.Check this for clarification. For experimenting you can try opening more than one apps from your recent apps and then return to your app. It may crash there too now.
You stated that you can see that the activitiy is stopped (onStop) if you go to the settings. That is the behaviour shown in the Android activity lifecycle. The counterpart for onStop is onCreate. So it does what the documentation tells us. Btw activities are paused if they are visible in some way and get stopped if they are not visible anymore. This would explain why your activity get paused. For further information read Managing the Activity Lifecycle. You can find a whole picture of the lifecycle here.
This type of behaviour can be seen when you change some system configurations like font type,font size or language. But turning wifi on/off won't destroy the app and recreate it again. Check http://developer.android.com/guide/topics/manifest/activity-element.html#config for more information