I have an app I have building that is giving navigation from a location to a location. Contstantly tracking where the user is using GPS data in order to give good Directional information. Currently if a user switches from our app to another app or goes to the Android home screen, after one minute Android turns off our app for performance reasons.
I have tried using an Isolate but like flutter this gets shutdown. Next step were to use a kotlin service to handle background things but i wanted to check if anyone had done this in dart yet?
Also this is not an app that will be in the play store or on public devices. It is going on special devices that we control and are less worried about memory usage as this will be the main app ran on them.
as mentioned above in the comment by #galloper background_fetch is the thing you need, it has a method called BackgroundFetch.registerHeadlessTask(backgroundFetchHeadlessTask); where backgroundFetchHeadlessTask is a function that will keep running even when the app is close, i used this in my app to stream location info to server.
I am developing two apps:
-> App A: it connects to a Bluetooth device, retrieve some data, process this data and broadcast an intent to App B
-> App B: it receives this intent and shows the results.
App A must keep running in order to keep sending data to App B.
Everything was working fine until this week when I made some visual changes and update my android device to V7.0.
Now, My App A stops (DEAD message in debugging window in android studio) when I switch to App B and see the results. If I change back to App A, current activity restarts itself and it works normally once again.
I do not get any exception or error message in android studio's debug window.
Any idea or information about this issue. I must say I have read a lot of questions and documentation but I can not find the reason of this issue.
(sorry for bad English)
Everything was working fine until this week when I made some visual
changes and update my android device to V7.0.
7.0 has introduced numerous changes aimed at improving battery life. Your App A is likely suffering from these changes, particularly if it was memory / cpu intensive, which it sounds like it might be.
App A must keep running in order to keep sending data to App B.
If that's the case, you probably want a make App A a foreground Service to ensure it keeps running.
Architecturally this probably makes more sense anyway if your use case is to have App B open while App A keeps piping data to it. The fact that your App A was not dying before was likely just lucky chance. It would have been killed by the system eventually after going into the background.
I have a Bike computer app that logs data while the user is riding. I have had a user report an issue I had not considered. He was out for a long ride (100+ miles) but while out and logging data the app got updated via Google plays auto-update. This unfortunately killed off the app mid recording and the user lost data till they spotted what had happened and restarted the app.
Ideally I would like to be able to programmatic stop the auto-update happening while the app is data logging. All my research indicates that this is not possible possible but I may of missed something so dose anyone know of a way of doing this?
Given no solution the best I can do is advice the users to enable the update only over wifi option in the Play app which in this instance would of helped. Unfortunately one of the key points about my app is that it will log indoor sessions using ANT+ sensors so I have a good number of people using it with wifi active.
Edit
I managed to do the experiment to see what happens myself last night. I had an app going in the background data logging then pushed a new version to Google Play. Unfortunatly it was not picked up totaly automaticaly when I had to leave 10 hours latter but I opened up the play store app and it found the update it did not start updating automaticaly but I forced it. The act of downloading and installing the new version killed off what was in progress. It was already dead before I used the notification to go to the new version.
As you say yourself, you can't do that what you are asking for. You could hack your way around it by changing the permissions each time you update. The users will then be prompted about it in the regular way.
I'm not sure about the "life-cycle" for automatic updated apps that are running. But I read somewhere that is wasn't the re-install but the reopen of the app that crashed it. If that is the case you could set a flag indicating that the user is currently logging and then on restart just resume the logging. But again we need to know more about the inner workings of activities/apps which are running and get an automatic update (actually didn't think it could happen).
Edit
Based on your findings I'd say you have to handle the app is shut down in onDestroy etc. or/and make sure you save everything persistently. Then you might need to have 2 apps where 1 listens to the other being re installed and when that happens it starts it up again (there is an interesting discussion here). If you are targeting api >= 12 then the broadcast action ACTION_MY_PACKAGE_REPLACED might also have interest.
I have written a simple database program in android. It runs fine, there is no force close error. But I checked from my application from Settings App I see the Force Close option enabled, which implies that my application is still running in the background, even though I have completely came out from my application to the home screen by pressing back key. And moreover I am not using any services, alarm or broadcast things.
Can some one please guide me what may be the probable reason?. Or is it okay? Or will it crash if I put it on device?
Can some one please guide me what may be the probable reason?. Or is it okay? Or will it crash if I put it on device?
Your application is alive until Android OS needs more memory and destroys it. What I have understood does Android start destroying activities before killing the whole application. This means that your application can be alive even if you have finished your activities.
Do not worry about this; Android OS is handling this extremely well.
Android doc say:
"When the system, rather than the user, shuts down an activity to conserve memory, ... "
But how to simulate this situation?I want to debug the onRestoreInstanceState(Bundle) method,but don't know how to.
You can't do it in an automated way b/c its completely non deterministic.
See my answer here: https://stackoverflow.com/a/15048112/909956 for details.
But good news is that all you need to do is just simulate calling onSaveInstanceState and you are indirectly testing this low memory situation.
onSaveInstanceState can be triggered by:
losing focus (by pressing home which in essence is like switching from your app to launcher app), launching another activity, pressing recents
changing orientation. this is the easier way if you are using an emulator
changing developer setting: goto developer options --> Apps --> Don't keep activities. This is best option if you are testing temporarily on an actual device.
I've used the "Don't keep activities" developer option to reproduce a crash that happened when an activity was killed due to memory pressure. You can find it in the Apps section of Settings->Developer Options.
It destroys every activity as soon as you leave it. E.g. if you press home to put your app in the background the current activity is destroyed. See https://stackoverflow.com/a/22402360/2833126 for more information.
There's two way to simulate the android killing process: using the setting "Don't keep activities" in developer settings or killing the app process by yourself.
To kill the process, open the activity you want to test, then press home button to send your app to background, and then, using the DDMS in Android Studio (Android Device Monitor), select the process and then stop the process (as seen in the image below). Your app was killed. Now, open your app again (accessing the list of open apps). Now you can test the killed state.
For the purposes of debugging onRestoreInstanceState(), just change the screen orientation ([Ctrl]-[F11] in the emulator). Your activity will be destroyed and recreated, and the onSaveInstanceState()/onRestoreInstanceState() pair will be invoked.
Use the SetAlwaysFinish app (works on a real device and in the emulator) or use the Google DevTools app (works in the emulator only).
These apps use the hidden AlwaysFinish setting of the ActivityManagerNative class to change the behavior of the OS and cause it to immediate unload every activity as soon as it's no longer in the foreground. This will reliably trigger the onSaveInstanceState and onRestoreInstanceState events.
See link below for more details:
http://bricolsoftconsulting.com/how-to-test-onsaveinstancestate-and-onrestoreinstancestate-on-a-real-device/
To debug onRestoreInstanceState you could do the following:
make sure you can debug application right after its start (calling android.os.Debug.waitForDebugger() from your constructor helps, it hangs your application until debugger is connected),
put you application in some state,
causally kill it from Settings->Apps,
causally switch back to it through Recent Apps button (it will still be in the list),
at this moment your application will be started anew and onRestoreInstanceState will be immediately called on the top activity.
Good answers here.
Now, residing in the distant future, using Instant Run in Android Studio will also trigger a save and restore when activities are restarted with code changes.
There's a decent solution for this in Android 6 and newer. See my answer here: Simulate killing of activity in emulator