I've read all the questions related to quitting Android application. But I could not find the answer to my problem.
So what is my problem. My application is a music player written in Qt (C++/QML). I wrote it especially for my car. First it was a UMPC with Windows, now I have an aftermarket headunit with Android. I successfully ported my player to Android.
Now I try to solve following issue. If I shut off my car, the Android "computer" inside my radio also shuts down. I would like to save the current track and the track progress so I can resume it on next start.
Is it possible to catch the signal from Android that my app should close and save the settings? Or does Android kill my application without giving me a chance to react to it?
Currently I'm saving the progress to a database every 10 seconds. But I feel this not ideal. I would like to know how applications are closed in Android in these situations:
1) The app is in background and OS decides it needs more RAM and terminates it
2) User invokes app switching menu a swipes my application away
3) System shuts down
4) A "battery saver" (task killer) closes my application
Can I react on some of these situations and do something before my app is closed.
If you use ApplicationWindow (you mention you are using QML so you should be using that) it is trivial:
onClosing: {
saveYourSettings()
close.accepted = true
}
Related
How do you go about detecting what app is currently running on the foreground when using react-native.
My RN app will be running in the background and needs to be able to detect the launch of specific apps within the phone. For example if the user opens game, how would i go about detecting what the app opened is (app package id).
I read that android native has this feature, through reading this stack overflow question detect apps running in foreground
I would like to know if there is a process similar in react-native, help would be much appreciated.
Thanks.
I'm developing an augmented reality app with Unity where users can shoot a photo with their mobile device to add 3D objects on it. The problem is that on Android, when the user chooses to shoot a photo from my app, the app is put on the background and often closed instead of being kept in memory to handle the photo taken. I know it is because of Android killing apps to free ram.. But is there a way to prevent the killing of my app ? Even on Ipad 2 with its 512Mo of ram IOS doesn't do this brutal killing thing : after the shooting it goes back smoothly to the app. Whereas Android does it with my 1Go of ram phone.
Also I do not want my app being killed and restarted by a service to handle the photo because it is pretty heavy to load and so really far from starting instantly.
Application.runInBackground is disabled on mobile platforms and therefore Unity cannot guarantee that your game/app is kept running. This behaviour is normal as the OS kills activities as needed. Sadly Android is resource hungry and therefore apps that stay in the background on iOs might be killed on Android, even with better hardware.
As hinted in this thread you have a few options: use states to handle pause/resume, create a service that will keep running in the background (it will have to be created outside of Unity either via a plugin or in eclipse) and/or use Android's intents mechanism.
As the title says, is there any predefined time set in the operating system that will close any application after some time? in my application I have a process that takes around 5 seconds to complete in pure java. And I know that I should put this in a AsyncTask, just asking the clearify this. Thanks!
It varies from device to device and depends on what is running on the device.
Hope this example gives you a fair idea of what can happen.I'm currently developing an app that uses the camera via intent.
On the Acer Liquid, it went to the camera and returned but on the Sony Ericson Arc, the app was killed in the background almost immediately after the it left my app to go to the camera.
After a restart of the Arc and running the app again, it wasn't killed. Started a few other apps and tried again and it was killed. The Liquid on the other hand would keep the app running four hours in the background even if I started a bunch of other apps.
There is no standard, it varies from device to device, manufacturer to manufacturer and what's currently running at the time.
I'm wondering if it's possible to develop an android app that will be run in sort of a kiosk mode. The idea is that the user should only be able to interact with the phone through this app.
I understand that an app can be auto-restarted, and things like avoiding incoming calls, could be implemented via a service that would subscribe to the telephony events and would hang up when an incoming call is received. The downside of this is that the usual "answer call screen" would pop up for a short period. The reason behind this is that the stock android app that receives the incoming calls will still be there.
I also understand that, by design, this custom app could be killed at any time by the OS if memory usage gets too low. Although this should only happen if there's a memory leak in any of the running apps.
I'm not sure either if it would be possible to disable the behavior of the physical buttons to access home or settings screens.
I understand that rooting the device and/or creating a custom ROM with modifications would be a safer approach, but also more complex. I'm wondering if a good-enough kiosk mode could be implemented with an android app.
P.S: I'm sorry for reposting these questions, but answers to similar questions are not clear enough.
Make your application be a home screen. That can still be bypassed unless you make your own custom firmware where your application is the system default home screen. We cannot tell you whether being a home screen alone is "a good-enough kiosk mode".
I've been searching for this for days now, nearly every answer is not a complete solution at all (and it's doing my head in)
This link though has the best answer so far
http://thebitplague.wordpress.com/2013/04/05/kiosk-mode-on-the-nexus-7/
why cant android os be more like apple os on the the ituch/iphone? where the app doesn't run until it is selected. it is also closed; stays closed until it is opened again.
i think this would make the android phones run faster and more efficiently(battery would last longer).
A lot of Android apps (I think most of them) run exactly as you describe it - they have an activity that is closed or suspended as soon as you leave it - a suspended Activity only consumes memory and can be discarded in an instant. (iOS does nearly the same)
Even on the iPhone there are applications that run in the background, the most prominent example being Mobile Safari. The difference is that only Apple can write applications that run in the background without restriction, and that a regular user has no way of monitoring these background apps. (this has led to massive overcharging issues in the case of users leaving Mobile Safari on a page where streaming content was loaded.)
There are legitimate use cases where you need an app to continue running in the background (downloading, uploading, playing music, waiting for a VoIP call) - none of it was possible for a third-party to do it on the iPhone until iOS4, making applications such as Pandora or Skype nearly useless.
For good or ill, Apple consistently restricts what third-party developers are allowed to do on iOS devices (App Store policy, private APIs, specialized APIs for background tasks mentioned in point 3). On the other hand, Google seems to prefer that third-party Android developers have access to the same APIs as Google's Android app developers.
The biggest Android performance problem IMO is responsiveness, the fixing of which is a lot more involved than saying "no Apps in Background thx". (See http://android-developers.blogspot.com/2010/12/new-gingerbread-api-strictmode.html for more information)
An Android developer's blog explains the reasoning behind Android multitasking.
We did not want to require that users close applications when "done" with them.
Mobile devices … have fairly hard limits on memory use.
These competing constraints were a key motivation for Android's design.
The fact that you can see an application's process "running" does not mean the application is running or doing anything.
The articles linked from there also have interesting things to say on the subject
The RadioActive Yak:
When should your app include an exit button? The Short Answer: Never.
Wickenden:
One of the first things the naive but technically inquisitive new android user does is begin to wonder how all the things they are running should be “shut down”.
Google’s android system has been designed for multi-tasking in ways that allow programs to be ready to respond to a changed environmental condition instantly (an alarm to wake you, a notification that you have arrived at your destination and so forth) as well as actually “running” and consuming resources when needed. Additionally the android system itself is smart about how it deals with low memory conditions and is capable of completely blowing away applications in such a way that their state is remembered and can be restored when there is more memory.
Task Killers (whose behavior is radically clipped in Android 2.2 “Froyo”) actually can cause harm by destroying a process that other apps need to function correctly.