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?
Related
I made a simple app that responds to vocal commands using PocketSphinx to understand commands and standard Google's library to speak, in a sort of conversation.
It's working well but I have a problem and I'm unable to undesrtand what's happen: after the screen goes off, but maybe it happens also after a while, without talking for a while, when the screen is on but opening another app, the application stops retrieving my vocal commands.
When I unblock the phone and/or return to the application, everything restart to work without problem.
I need that this application works in the same manner also when the phone is in standby, but I can't understand what could be the best solution (the best or simply the possible one):
does using wakelock could change something?
does transorming the activity in a service could be the solution?
I tried to disable battery optimization too, and also I tried with an exernal application to impose PARTIAL_WAKE_LOCK to mantain the CPU on, but nothing change.
Does someone has got some experience in this case and can explain me how to do?
Thanks a lot in advance!
I am creating application that has endless ForegroundService for new android versions.
Problem is that ForegroundService always dies after some time no matter what.
Tried to do Battery optimization, Wake lock, creating new process for service, even creating JobScheduler that checks if Service still working, but that one also stops working after some time.
Tried to follow Google samples, Stackoverflow solutions and many others, nothing seems to work.
I also made some research on my banking app and some other apps that relies on services for notifying the user or tracking some activities, they also not working flawlessly like old times.
At the end I figure out that for some Vendor phones doing some extra setting Vendor specific setting helps, this link one of many examples to understand Slack Known issues with Android .
After this reading, I don't think that simple user should go somewhere in to deep phone setting to make app that he likes to work... In fact I think it is the worst practice....
Made some conclusion after researching that because of saving few battery percents Google and poorly made Vendors battery saving strategies on top making phones dump and not reliable....
Also these background restrictions making not possible to develop awesome pocket portable device features...
I mean I agree with ForegroundService idea for long running task instead of simple Service in background that might be malware, spying or whatever that user does know nothing about it. Also agree that User is notified about high power usage, but randomly killing everything is same as killing the idea of smart device.
Please tell me that I am wrong about everything and give me a solution :)
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.
I am writing an app to evaluate the feasibility of a Bluetooth P2P network on Android.
I noticed that on a Galaxy Nexus, it uses very little battery, while on a Nexus S, it drains the battery very quickly. This is directly caused by high CPU load due to Bluetooth.
Now, I would like to collect information about how much battery drain my app causes on the devices it is installed upon. Simply logging time vs. battery level is useless since I don't know when the device is in use, and even if I logged that, I would not know if the user is playing 3D games while Torrenting over WiFi or reading an eBook on a dimmed screen.
To make the problem worse, not all battery usage caused by my app is attributed to it in the battery screen - some is listed as "Bluetooth", for example (again, device-dependent).
Is there any easy, privacy-preserving way to get useful information on non-rooted devices? The devices are not under my control. I cannot simply go look in the menu, I cannot use ADB.
The Android API doesn't support this currently. The only available documentation is the one describing how to use BatteryManager's broadcasts, which only supply the overall battery level and no per-application details.
I suppose that even if there are undocumented ways to emulate what the System Settings battery manager shows, they would require rooting.
AFAIK there is no way to do this. The closest you can get to doing this is to hook up the device to a monitoring tool like little eye labs which does draw the battery consumed by your app over time on a graph. It also supports marking key events in the app's lifetime like turning on WIFI / bluetooth etc.
There is no support for doing this remotely, but you can get the data on your own test devices.
This approach is quite crude, but it may help. You can use the existing BatteryManager broadcasts to track changes to the overall battery level while your app is active.
Knowing when your app is active is a separate issue. If your app consists entirely of Activities, then you can get good results by starting to track whenever any of your Activities' onResume() methods is called, and stopping tracking in onPause(). If you can have all your Activities derive from a single base Activity class, then this is quite easy. See How to detect when an Android app goes to the background and come back to the foreground for suggestions on how to track this.
If your app is more complex, and the smart stuff happens in a longer-running component like a Service, then it's much harder.
This is crude, but at least it would help you distinguish "playing 3D games" from "using my app".
Background
I'm developing a research application that runs on Android phones. In short, the application runs so long as the phone is on and periodically takes information from many components and sensors on the phone. The application is to disturb the user as little as possible. That being said, it's draining the battery far too quickly and forces the user to recharge every day. This simply won't do.
To try and figure out how to improve the situation, a colleague also working on the application let the application run for a long period of time and noticed that the biggest battery hog is WiFi. My current idea is to manually shut off WiFi when it's not in use in an attempt to save power. AFAIK, Android uses PSM for WiFi to accomplish this to some end, but it doesn't seem to be enough.
Problem
Is there a way to "ramp up" Android's PSM? Or, if there is not as this question suggests, is there any way that I can safely turn WiFi on and off without adversely affecting the user? I.e., is there a way to tell which applications are using WiFi and turn it off when none are? Do standard applications - such as the web browser and email clients - use WiFi locks to prevent WiFi from being turned off when they are working?
Any advice on where to start in solving this problem are greatly appreciated. Information on how Android's PSM works, how long it takes for it to take effect, or any information relevant to the problem are very welcome.
Thanks for your time!
Is there a way to "ramp up" Android's PSM?
Not via the Android SDK.
I.e., is there a way to tell which applications are using WiFi and turn it off when none are?
The OS does this already.
Do standard applications - such as the web browser and email clients - use WiFi locks to prevent WiFi from being turned off when they are working?
Some probably do. You are welcome to search the Android source code and find out. Of course, bear in mind that there are no "standard applications" -- I presume you are thinking of the ones that are part of the Android open source project.
Any advice on where to start in solving this problem are greatly appreciated.
Find out where in your own code you are being inefficient, specifically here:
the application runs so long as the phone is on and periodically takes information from many components and sensors on the phone.
If the device behaves fine when your code is not running, and the device does not behave fine when your code is running, then the problem lies in your code. Conversely, if the device does not behave fine even when your code is not running, then something else is afoot (device defect, firmware defect, rogue application, etc.), but it probably has nothing to do with StackOverflow.