This discussion (in the comments) raised an interesting question :
What is the result of calling exit in an Android app (with regards to the android life-cycle) and can that damage the OS ?
What is the result of calling exit in an Android app (with regards to the android life-cycle)
The Android documentation for System.exit() says that it "Causes the VM to stop running and the program to exit." I just tried it and it seems to kill the process for the app that called System.exit().
In the Android Developers thread named Activity.finish() x System.exit, someone corroborates that "System.exit() kills your entire process."
Dianne Hackborn aka hackbod goes further "To be clear: using System.exit() is strongly recommended against, and can cause some poor interactions with the system. Please don't design your app to need it."
and can that damage the OS ?
It should not damage the OS. Android will just let your app kill its process, not any other process on the system. It will keep the rest of the system running while your app ends.
I also verified this by running two applications and making one of them call System.exit(). The other was unaffected.
Related
I am struggling with a strange situation with my Android app.
It runs on a 5.1 OS and the device is Rooted.
The app is running fine for a few days and then from an unknown reason it crashes (WIN DEATH without any exceptions from my logs).
I think it related to an internal memory leak on a specific Android model I'm using.
Anyway, I need to restart the app in cases like that.
Unfortunately, using 'Thread.setDefaultUncaughtExceptionHandler' method doesn't help because it won't handle those situations (the app is crushed).
I thought about creating a second app that samples the state of the process and if it is disappears from the process list, it starts the activity.
Is there a more elegant way to handle this situation?
Thanks a lot!
Asaf
I am developing an android application in which i need to perform an action when other apps are closed / force stopped. This detection has to be made from a service which is been running in the background once started. Making the service to run continuously is not a problem but making detection when other apps are closed is the problem. Please do anyone have any solution.....
I don't believe it's possible to detect when an app is force stopped. Even the app being stopped doesn't get that information. You can detect if an app is currently closed by using the BroadcastReceiver. Here's a pretty decent tutorial on using that: http://saigeethamn.blogspot.com/2009/10/android-developer-tutorial-part-11.html
I am not aware of any official way in which Android allows apps to listen in on when other apps are forced to close. So you’d have to poke around under the hood.
Disclaimer: Doing so is unsupported. While just reading information is unlikely to cause any harm, there’s no guarantee that it will work universally. If you get it to work on your particular build of Android, may still fail on different builds. Also, Google keeps locking down features in Android with every new version, so there’s a high likelihood a future update may break things.
I haven’t actually tried any of the below, hence there is a possibility they will fail to produce the expected result.
That being said, here are a few things you can try. You may need to combine them to get something useful out of them.
Processes
Since Android is based on a (somewhat) modified Linux kernel, it generally supports most Unix mechanisms for working with processes.
Apps are launched by a process called zygote. A quick run of ps on an Android device shows me that all user apps (as well as the higher-level system apps) seem to be children of the zygote process. Thus you could get a list of all processes, find the PID for zygote and grab all its child processes.
Then you might be able to waitpid() on each process and examine its exit status. You may want to experiment around with this a bit and see if the exit codes tell you anything about how the process ended.
Also take a look at ptrace(). You might be able to monitor zygote directly with an option such as PTRACE_O_TRACEFORK, which should basically notify you each time a new app is launched, allowing you to monitor its PID as well.
Downside: You probably need to be root to do any of this. Linux doesn’t let users see other users’ processes (which is an essential security feature), and Android harnesses (or abuses) the user model by running each app with a separate Linux UID.
Logcat
Looking at various logcat apps (e.g. aLogcat), you might be able to monitor the logcat for events like this:
12-26 10:01:27.670 I/ActivityManager( 774): Process org.openbmap (pid 21647) has died.
There are a few events that may occur when an app crashes—ActivityManager will tell you when an app has died, or you might watch for unhandled exceptions.
Note: While this doesn’t seem to require root (aLogcat works fine without), it may not work under all conditions. I have seen devices where aLogcat sees next to no entries, though I didn't investigate why. In those cases, the above approach would not work as it depends on being able to read the logcat.
I have almost the same issue as where described here, answer in this post doesn't help me, I release my equalizer immediately after setting band levels to it. It works perfect on my 4.0.4 device, it works great on friend's 2.3.5 device, it crashes on a little percent of devices and it doesn't matter which version of android is running on these devices.
So there is error on
Equalizer mEqualizer = new Equalizer(0, mediaPlayer.getAudioSessionId());
java.lang.UnsupportedOperationException: Effect library not loaded
at android.media.audiofx.AudioEffect.<init>(AudioEffect.java:355)
at android.media.audiofx.Equalizer.<init>(Equalizer.java:149)
I have no idea how to solve this, any suggestions?
Make sure that you reboot the device and test it again with the release() after using the equalizer, it worked for me after 2 days of searching for clues.
From the documentation, you have to call release() on an Equalizer, MediaPlayer, Visualizer, etc for a graceful exit, or you will see this error when restarting the app. The only remedy then is to reboot, as previously mentioned in this thread.
This is where the Android application lifecycle makes things a little difficult, since apps are never supposed to exit (just pause and resume), unless absolutely required by the OS for memory reasons, or a reboot occurs. Your app onDestroy() method is called in both cases.
You can put the release() in onDestroy(), and that would satisfy the Android lifecycle for deployed apps. Your users would not see this error.
In development however there is a problem: IDEs like Eclipse (which is actually a framework for building IDEs, and not meant to be an IDE itself...) will kill the app process instead of sending it a destroy message. This violates the lifecycle and release() is not called.
This is also why you should never call System.exit(). It violates the lifecycle at the risk of ungraceful exits exactly like this.
So your process was exiting ungracefully. Only happens in development, not deployment. One remedy is to not use the device window in eclipse to stop processes. It is not a stop, but a kill.
Eclipse also kills (lifecycle violation) the process ungracefully when you Run an app project while there is already an instance running.
As the doctor said, if it hurts, don't do it: instead use the debugger which sends actual lifecycle messages to the app.
This depends on the build of Android that is loaded on the device.
This log means that there is no library to implements the AudioEffect feature.
I m afraid there is no solution for this, rather then importing into your project some third party audio effect library
I need to run my android application (written in Flex) in the system background, so that periodically performs some defined task. Unfortunately I can not find any hints on the Internet:( I would also like to know how such an application to restore from the system background?
Please help if you know the solution.
Thank you.
Best,
Martin
I need to run my android application (written in Flex) in the system
background, so that periodically performs some defined task
Technically you should be able to minimized it on launch; however for performance issues non active applications are throttled. That means everything--including timers--will run slower than expected. So, 1 second on your timer will not necessarily equal 1 second in the real world when the application is inactive.
Unless it will be okay for the user to manually trigger your tasks; you should consider an alternate technology for the implementation. AIR is just not usually suitable for background applications.
What's the difference if I call System.exit() vs. killProcess().
I am interested in difference only
I dont think There is any difference. although with System.exit(), you should call runFinalizersOnExit first
What should we use?
No one, read this Is quitting an application frowned upon?
It looks like System.exit() is just as good in every respect as kill -- but much simpler and less dependent on other things.
Some have suggested that runFinalizersOnExit be set but according to the docs that is considered unsafe and is phased out as of 1.0 -- so I guess ignore that part.
Contrary to other suggestions, finish() does not end the Linux process which is running the app and does not free up all the memory used by the app.
Granted, android is designed so that for many cases there's no particular need to actually exit an app (At the cost of a slight pause later, android will kill your old apps when it needs their memory) -- however if you do want for any reason to kill your app System.exit() seems to be the idea way. It shuts down the java virtual machine which is running your app - so all resources, memory, and threads will be completely flushed out.
(Note that you can specify in your manifest file that some threads should run in different linux processes -- in which case System.exit() would probably only kill part of your app - but that's more advanced stuff.)
As a matter of fact, I just ran adb shell ps|grep app and I see the com.example.android.lunarlander sample app which I haven't run in about a week -- still in memory, still taking up almost 100000 bytes of memory.
Neither. Use finish(). See this, and the link aromero recommended. Let Android do what what it is meant to do: manage your activity life-cycle. It was designed this way for a reason.