I want to know whether my app has crashed or exited by the user. Is there any way to do so?
See this: https://developer.android.com/reference/java/lang/Thread.html#setDefaultUncaughtExceptionHandler(java.lang.Thread.UncaughtExceptionHandler), it may help :)
There's no such thing as exiting the application by the user. You can always do something when onStop() or onBackPressed() of your main activity is called, but that's all. Just note that it doesn't mean that the app was "exited", but only "left" by the user. You can of course finish the activity from there to make sure the app is really exited.
Technically, there's no exit ideology in Android. Applications are kept on running in background and (if necessary) Android's VM automatically kill stale applications when it requires to free memory.
Regarding app-crash, if the app is crashed, so you may get notified on your Google Play's developer console in case the user has chosen to report the crash.
Related
About Android (6.0 to the last version)
I'm developing an app and we want that the user, once he accepts all the terms, don't be able to kill the process or force stop the app. Honestly, I'm completely lost right now, because on the last versions of android, and specially some brands like Xiaomi, we are having a lot of trouble with it, and we don't know how to act right now.
In the case that it could not be possible, could at least get an alert whenever the user is killing the app?
Thanks!!
It is not possible to prevent the user from killing an app. Android is a unique system where the app has no direct control over its lifecycle but the system has. The system can (and will, when required) kill the app or any of its processes at its own will. To make your app aware of these changes, the android framework provides for various callbacks such as onPause, onStop and onDestroy which are called in succession when the user kills the app.
Side Note : There is no guarantee that onDestroy() will be completely executed when the app is killed. Do not place essential code there.
Of course, you can block or try to prevent the user from closing your app by overriding the back, home and recent buttons but it is highly recommended not to do so. Even if you do so successfully, the user has other means to close your app such as rebooting their phone.
So what to do?
You are looking for a kiosk mode app. Kiosk mode is used for single purpose phones such as at a restaurant or for a cab driver. Kiosk mode apps lock down the user to only a specific app (or a specific set of apps).
For normal apps, it is not possible to prevent the user from force closing your app. You can only get alerts by checking for lifecycle changes as described above. Moreover, it is not at all recommended to change the natural behavior of the hardware buttons on android. The user can still find a way to close your app. If your app is doing something really essential which should proceed in the background, consider using a service for that instead. Also, the user can uninstall your app at anytime if they find your app being too intrusive and you won't be able to do anything in that scenario.
Tl;dr: Use kiosk mode to prevent the user from exiting the app. This will only allow the user to access your app(s) in their device.
Usually you cannot! Even if you try to disable some buttons, user can always stop app or restart device. In addition at times, the OS will stop the App. Your responsibility as a programmer is to program around this, and give the user the feel that it never stopped. If you are doing background monitoring, you will need to use service. Users will still be able to stop service. Having said that, you can set your app as a Device Administration app, see here, which may disallow stopping, but unless you are distributing internally to a company, noone will install.
I have an android application which was supporting till lollipop. Now I'm migrating it to support Marshmallow.
I am stuck in a case where if we manually changed the app permission in marshmallow it kills all the process.
I get it as explained by #CommonsWare in similar question here.
But in my case I have to kill the app and need to restart the app. Because my app each activity is dependent on previous activity some data is shared. I just need to know when we manually change the permission is there a way our app get noticed.?
I meant any callback occurs. if Not is there anyway I can handle this case.? Please Let me know if the question is too broad I'll update my question
Thanks in advance
I just need to know when we manually change the permission is there a way our app get noticed.?
Your process is terminated. This is indistinguishable from any other reason why your process might be terminated.
I meant any callback occurs.
No. You get ordinary lifecycle callbacks (e.g., onPause(), onStop()) as the user navigates over to Settings to be able to revoke the permission, but that's it. There is no specific callback related to losing the permission.
Also note that the user could leave your app, your process could be terminated for other reasons, the user could then go into Settings and revoke your permission, then the user could return to your app. If all of that happens within ~30 minutes, Android will still try to rebuild the outstanding task. You certainly would not get a callback of any sort in this case, as your process was not running before the permission was revoked, let alone after.
I'm trying to write an Android service, which starts on boot and works in the background periodically. I have defined the BroadcastReceiver of mine, added the right permissions and all the necessary stuff in manifest.
When I install the APK on my phone and reboot, nothing happens, the program is there in the installed apps section, but not running.
I've seen a user comment stating that "standalone" services are disabled (for security reasons?) since Android 3.1 but I couldn't verify this information anywhere.
Anyone could give me a clear view about this? Without that, I don't know how to proceed: debug or change plans.
Thank you in advance!
Just after the first the first installation of a package, the application is in a "stopped state" preventing it to execute any code for security reasons.
The app loses this particular "stopped state" as soon as the user launch the app explicitly for the first time.
I was wondering if I can kill app from other app. I mean I want to create application which when I start this application I will check status other application and if app, which name is for example "Startex" is running then I kill "Startex" app and run my second application.
No you can not. Only Android can kill application if it needs memory. In order to do this you should know the PID of the application you want to kill and invoke a syscall at kernel level
If both apps are designed by you then you can have shared user id in both the Apps then you can kill another app here is the way.
This can't be, or at least should never be done. Android itself is supposed to control when an app is no longer required, usually based on needing to free up some memory for another app that may be opened. Google frown upon developers killing the app themselves without letting Android handle it, and likely would never receive any promo place on the play store from Google.
I noticed that after I quit an app using the back button, when I go to the "Manage apps" menu I still have an option "Force Stop". Shouldn't the app be already dead at this point? (I made sure that OnDestroy indeed runs).
Why would I have an option to force stop an app that's officially dead?
Thanks,
Geva Tal.
I noticed that after I quit an app using the back button, when I go to the "Manage apps" menu I still have an option "Force Stop". Shouldn't the app be already dead at this point?
No.
Why would I have an option to force stop an app that's officially dead?
Because the process is not "dead". Android will keep your process around for a bit, in case the user happens to pop back into your app in the not-too-distant future. Android will terminate your process if and when it needs the RAM to support other apps.
The behavior you are seeing is perfectly normal.
Using the BACK button finishes an Activity, i.e., the current UI part of an 'app'.
A common mistake is to assume that an Activity is the entire 'app' which is not necessarily the case. As CommonsWare points out, it is not necessary for the OS to immediately clean up all of the parts related to the process in which an Activity runs - in fact it can be counter-intuitive if a user briefly leaves an Activity but then re-visits it shortly after.
Android is actually very efficient at managing resources and releasing them (if needed for other 'apps'). What gets retained / maintained after a particular Activity finishes isn't worth worrying about...or at least it shouldn't be if the developer has correctly cleaned up things in their code.
Part of the culture of 'App Killer' apps is related to people assuming that apps don't clean up properly when an Activity finishes. If written correctly, they do and Android will do the rest if/when necessary.