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?
Related
Proglem:
Create custom Android App which will never be killed by the platform.
Given a Dialer app (or a phone-app), for making calls on Android Phone, is there a way to similarly create custom app and make it a system app, so that Android always keep it running?
In other words, the problem we have is to deploy an app which will never be killed by AOSP due to lack of resources or anything similar, which is what I think android does for Dialer and some other system apps/services.
Possible helpful hint: The device will always have power supply, as it is not a phone/tablet but rather a custom device running custom AOSP.
I am working on an Android application that uses Bluetooth to communicate with a nearby PC.
The app works greatly on my own device (Samsung Galaxy Note 3 - CM 12.1) but on of my beta-testers it does not.
Simply put the app allows people to write and receive SMS from their
PC (with my C# WPF app) via Bluetooth & their phone.
My beta-tester is using a Samsung Galaxy Note 4 stock ROM (Lollipop).
At first I thought when his screens turned off, Android would kill the MainActivity which holds on a few threads including the one maintaining the connection alive (with a inpustream.read() blocking method). Such behavior does not occur on my own device : I could keep the connection alive for a whole night without plugging my phone.
I was warned, though, that using services would avoid such problem because Android does not behave the same way from one device to another. So I updated my app and made my MainActivity use my MainService to spawn the relative threads. But it did not change a thing.
As my title suggests, the problem lies with his antivirus and more precisely : AVG.
I have no knowledge on how such antivirus work on Android and I don't even use one. By freezing AVG with Titanium Backup on his rooted Galaxy Note 4, my app stopepd crashing and is now working perfectly well as intended.
So I wonder, how come AVG deciced to kill my app when the device screen turned off?
How should my app behave so that this won't happen with any other users using AVG or any other antivirus ? What should I do so that my app does not look as a suspect ?
I don't know exactly what the AVG did to your app.But I think that AVG may don't let your app force to turn on the bluetooth or use the Bluetooth when Android device is sleep or send/receive SMS.The AVG is one kind of antivirus apps that most of them have lots of permission request limited or power saving strategy,especially on rooted Android devices or the first part app already in the Android ROMs.
Try to make clear that what's the real point AVG did to your app.And then try to solve your problems with gentle and smart.
For example：
1.If the AVG doesn't let you use BluetoothAdapter.enable() to force to turn on the Bluetooth, try to use Activity.startActivityForResult() to let users to choose whether turn on Bleutooth or not.
2.If the AVG doesn't let you use Bluetooth when the Android device is sleep.You can try to use WakeLock.acquire() to hold the Android device.
3.If the AVG doesn't let you use SMS sending or receiving.You can changed another communication protocol, SPP or BLE or something else.
Maybe you have heard Xiaomi.If you are an Android Developer in China,because Xiaomi is very popular in China,you must deal with the adaption with Xiaomi,and then you will find that Xiaomi is really fucking for Android Developers in China.
Xiaomi doesn't some really amazing things to the original Android.For example:
1.
AlertDialog..getWindow().setType(WindowManager.LayoutParams.TYPE_SYSTEM_ALERT);
you can't alert the TYPE_SYSTEM_ALERT dialog on some xiaomi ROMs that they tell you nothing.
2.Xiaomi has modified lots of original themes.
3.Xiaomi has changed the Android alarm timing mechanism while the device is sleep which is called Wake-Up-Alignment.This is really terrible for the apps that with the function of timing.
The above problems are that I met in Android development, some problems I can resolve it, some you don't have any chances to change it.
Remember that:The adaption with Android devices is that you must make your users know you app works on most of the popular Android Devices,the developers try to make the app run on most Android devices,but it maybe not work on some Android devivces with customized ROMs or with some special third part apps.That's it ,that's true, that's Android.
If the problem can't be solved,it's not a problem!
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.
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.