Recently I have been helping my professor to develop an Android app, which is related to speech processing. Therefore this app involves lots of real-time computation including FFT and inverse-FFT. When the app runs in the foreground, it works okay. However when the app runs in Service, the app will become unresponsive.
Does anyone know the reason? Is it because when app is running in Service, its CPU consumption is limited? Can anyone give me some solutions? I am a newb in Android Programming...Thank you very much
Assign a CPU wakelock to the service. More information on wakelocks can be found at https://developer.android.com/training/scheduling/wakelock.html
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'm developing some Android devices that are constantly performing fairly intensive tasks.
I've noticed a strange issue happen (quite rarely, generally after 2-3 weeks of running continuously) where a device ceases to function, and all communications with it die. Since I don't have any access to these devices I can only assume that the OS has killed all running processes (there are several processes on it that communicate with several different backend servers, and they all disconnect simoultaneously)
I'm currently getting around this by implementing a firmware watchdog (by compiling it from source), but I am trying to figure out what is causing the devices to die in the first place.
Is there some android functionality that kills all processes and requires a reboot to fix? What can i do to avoid this happening? Are there any logs that I can view which show when this occurs?
Don't know what have done to the AOSP, but there do have some mechanisms to make a system reboot.
In init.rc, if a service is note as "critical" then if the service crashes more than 4 times, the system will reboot to the recovery mode.
In framework, if the a service belongs to core service and crashed, the system will restart the whole android, but not the kernel.
Temperature, there are two types temperature reboot schedule. One is CPU heat, but this has nothing to do with android, it is a CPU feature. Another, battery temperature, if a battery's heart is higher than expected, the healthd(a android demon on watching battery state) will notice the framework and the framework will reboot.
If the communication logic is written in a Android App, I suggest you to make this app as persist. This will make sure the app will stay in memory forever, and if the app is crashed, the system will restart this app. This may not solve you problem, but can resume the communication job.
I think it is not hard to figure out what's going on, usually the logcat contains the detail.
One of the explanations of your scenario is that the CPU overheats. In this case, not only the device will spontaneously shut down, it also cannot immediately reboot.
You may find temperature warnings in system log, but you can monitor this in your software, and throttle down CPU-intensive tasks to keep it from overheating.
I have a hybrid android application which using different features like vibration, WIFI,bluetooth etc. Recently i have made changes into WIFI locks which i need to keep available event phone goes into sleep mode as i want to do a streaming in background as well.
Currently i am facing a problem as phone battery started drain very quickly. I want to figure out how i can find out which part of application is very so long or taking too much CPU. I have tried DDMS tool to and use method profiling but result not showing anything interested here. I also tried battery historian but have no clue why my application consuming battery very quickly. Can someone tell me is there any other tool which i can used to figure out this problem?
There are a lot of questions on here about "My app drains battery! Why?". That is not what I am looking for. I am wondering about how to create an app which can get which apps are draining the most battery.
I know it's possible, because I've seen apps that can do this.
I think you could work it out by CPU usage:
Take a look at this answer:
CPU usage per application in android
I suspect you would need to continually run a command like this and parse the results into a database, combining previous results to work out a running tally.
Recently I have developed an android app . The app is ok . But the user is complaining that app causing battery drain . Even some battery optimizer app (Like Battery Doctor) suggesting my app to force stop as it is causing battery draining too fast . There are a lot of service (like sync service , socket service) and broadcast receiver is used in this app and alarm manager is used in the app. How can I detect actually which is responsible for battery draining ?
I addressed the major contributors to battery drain in another of my posts.
If I understand correctly, you want to identify which section of code (including libraries) of your app is the culprit.
Here's my suggestion:
Confirm that there is a problem: Get as identical a phone configuration as possible, say by having the user send a dump of all processes running on their phone, and confirm there is a problem.
Confirm that it's your app: run tests with your app running and without. Make sure you take several measurements.
(A) If you have a profiler, use it to profile your application and identify potential issues. (B) If you don't have a profiler, create some dummy input, and start exercising your app while cutting out different functionality. Measure the battery drain.
NOTE: If the drain is small, detection becomes an issue. It's the old signal to noise ratio thing. The smaller the drain, the more measurements you have to take to determine what it is. Of course, the smaller the drain, the less of an issue it is.