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.
Related
Though it may look odd but I am developing an application that will ran on a one specific device with Android 6.0.1 and I don't care about other devices. The app should accomplish a long (very long) running work without any user's interaction as a service in the foreground. In other words I'm trying to use the device as a small server. I don't have much experience in developing mobile aplication but I found out that Android OS interferes too much in applications life circle. And though application starts and works properly for some time it can be unexpectably killed with vague reasons.
So the question is how to prohibit Android system to interfere with my application? Is it enough to make the application an administrator of the device? Or may be Android devices can't be used in such cases and it's a waste of time?
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
}
I have an android app installed on device (4.2.2).
The device will never go to power save mode.
If i leave the app open for more than 30 minutes, the app closes automatically.
And no exception found in the log.
Is this default android behaviour?
If possible please share any links about this issue.
That is just part of how Android manages memory for activities using the Low Memory Killer, even if as of today devices running Android have vast amounts of memory, the same rules are still applied as when it was designed, and it was designed to run on devices with low memory, if you want to keep it alive without user interaction you might have to either use a Service, or maybe find a way to simulate user interaction.
If you have this behaviour just only 4.x, but under 4.x don't, try in Manifest to turn true largeHeap. You have to turn it on in apllications tag attribute. I hope it will help.
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.
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.