How can i check if my apk that i created is don't use too much of the battery and not arm the usage of the battery itself.
Is there any tests or code to do or add for that?
Thanks
Take a look at this page.
it covers all the different parts of the battery optimization process.
In order to monitor battery stats of the phone I'll suggest you Battery Historian by Google.
Background
Google has announced on Google IO 2018 something that's called "Adaptive battery":
https://youtu.be/ogfYd705cRs?t=3562
As a user, this sounds promising, but as a developer, this could be an issue in some cases.
The problem
They said it checks which apps are used more often using AI, and that the "OS adapts to your usage pattern" :
Adaptive Battery uses on-device machine learning to figure out which
apps you’ll use in the next few hours and which you won’t use until
later, if at all today
To me it sounds like it might be yet another step in the "war against background processing apps".
What I've found
Since this is very new, I haven't found anything of how it works, and if developers should be concerned about it and need to change apps.
Only things I've found are articles from user-point-of-view.
The questions
What is exactly "Adaptive battery"?
Should developers be worried when it's being enabled?
Which app components, background-processing classes, alarms, wakelocks, syncing classes, background/foreground services etc... - might be affected by it?
If indeed it can affect the nature of the app, is there any API to check if it's enabled, and act accordingly? If so, how?
How does it compare to other battery-saving mechanisms?
I agree, this “Adaptive Battery” sounds concerning. This new version of Android, named Android P, “puts AI at the core of the operating system and focuses on intelligent and simple experiences.” (1) On the developer’s blog, they quote, “For developers, Android P beta offers a range of ways to take advantage of these new smarts, especially when it comes to increasing engagement with your apps.” (1) It is pretty obvious that while they are trying to make their OS better for the general public, they have not forgotten their developers.
The two things that are the most concerning with Android P are the Adaptive Battery and Background Restrictions changes. I will try to answer your five questions to the best of my ability, but of course with Android P being in beta, not everything is ironed out yet.
1. What exactly is “Adaptive Battery?”
“In Android P we’ve partnered with DeepMind on a new feature we call Adaptive Battery that optimizes how apps use battery”(1). What Android is using DeepMind for is categorizing apps into different “App Standby buckets” which range from “active” to “rare.” Based on which standby bucket the application is put into, it will vary the restrictions on alarms, jobs, network and high-priority Firebase Cloud messages.
These buckets are: Active – meaning the app is currently being used. Working set – meaning the app is in regular use. Frequent – meaning the app is often used, but not every day. Rare – meaning the app is not frequently used. Obviously these buckets are not clear cut because they are dependent on the DeepMind AI that Android P is implementing. Please follow this link for a better explanation on what the buckets are and how they are used. Also, this link is the Appendix for Power management restrictions, that will also shed light on the Adaptive Battery.
They also say “If your app is optimized for Doze, App Standby, and Background Limits, Adaptive Battery should work well for you right out of the box. We recommend testing your app in each of the four buckets.”
2. Should developers be worried when it’s being enabled?
It looks like developers might have some cause for concern if they do not plan for this. Looking through the power management appendix I linked above, the biggest changes are how long jobs and alarms are deferred. However, it looks like if you force jobs or alarms, then they will fire.
I think, for developers, it would be wise to heed their warning of optimizing your application for Doze, App Standby and Background Limits. And if that is not the route you want to go, I would highly recommend at least make sure to test your app in each of the four buckets.
3. Which app components might be affected by it?
Because Android P is still in beta, these are subject to change. For now, the only app components that would be effected would be: Jobs, Alarms, Network, and Firebase Cloud Messaging. These are all effected differently based on the standby bucket that DeepMind decides they should be in.
Another note, I mentioned background restrictions and was going to elaborate a little on it here, because it is similar to Adaptive Battery in the sense of its limiting powers. Background Restrictions point out applications that have been using battery in the background, and allows users to put restrictions on them. “When an app is restricted, its background jobs, alarms, services, and network access are affected.” So if a user deems your application as taking too many resources, you will get restricted and it seems as if this is like being put into a low priority standby bucket. There are however, ways in the Android P API to check whether your app is restricted, which will be helpful towards developers.
4. If indeed it can affect the nature of the app, is there any API to check if it’s enabled, and act accordingly?
Yes, there are calls in the API that can tell you which bucket that you are in, and whether your app is being restricted as I said before. For example, you can find out what bucket that your application is currently in by calling: UsageStatsManager.getAppStandbyBucket()
Also, there are great ways to test your application using the Android Debug Bridge in each of these buckets. Just follow this link.
5. How does it compare to other battery-saving mechanisms?
This type of bucket battery saving way, to my knowledge, has never been implemented before. This is a new experience. However, I know that the background restrictions have been available since Android Oreo, where the users could see what apps were acting out. However, in Oreo the users could only see what apps were sucking battery, but couldn’t place restrictions.
An interesting example I found here: “So, for example, let’s say you really only look at Instagram at night. In that case, Adaptive Battery will learn this behavior and keep the app in sleep mode during the day, then wake it up when you’re most likely to use it.” That is an example they gave for Android P for how DeepMind will work to place applications into these standby buckets.
Overall, I do think that this is a good step for Android, who has always been plagued by battery issues. As long as developers are not spamming their users with wake locks, notifications, or other things that aren’t necessary, this really shouldn’t impact their application too much. However, this does make it so developers have to put in more work, like checking what bucket they are in and acting accordingly. Time will tell if this is a good step for Android.
Links
(1) - https://android-developers.googleblog.com/2018/05/whats-new-in-android-p-beta.html#androidbeta
(2) - https://developer.android.com/preview/features/power#buckets
(3) - https://developer.android.com/preview/features/power-details
(4) - https://www.howtogeek.com/352364/how-android-p-will-increase-battery-life/
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?
I am currently working on an app that runs on iOS and Android. The core of the app is written in C++ and allocates over time more and more memory. The thing is I want at the same time to be able to use as much memory as possible and ensure the stability of the app.
Of course, to do that I would need to know how much memory I can still use. This way, if I see after a while that I am going to need more than it is available, I could stop allocating instead of getting killed by the OS or crashing.
The problem is, after reading and trying different solutions, my feeling is the information that you dynamically get is not reliable enough. For instance, on iOS:
[NSProcessInfo processInfo].physicalMemory
This is one of the typical examples / answers I have read that seems not to be reliable. It seems that you cannot get enough information dynamically to make sure that you still have enough memory, because the OS will at some point kill your app if it uses too much memory and sends warnings before. But it also can kill other apps in between, so stopping when I receive the first one seems not to be an optimal solution.
After reading a lot of posts, I am a bit confused on the topic. Is there a way to know dynamically and reliably how much memory is left for my app on iOS/Android ? Or memory management from these OS is too unpredictable for that ?
Thanks for the help !
By design, you're prohibited by the operating system from ever using up all the physical memory on the device; what's more, the requirements of the operating system and the other apps running on it mean that the amount of memory your app can comfortably use will vary over time.
Therefore asking how much memory you have left to use isn't really sensible. You should design your app to use as little memory as possible, and then optimize until you use less than that.
Be aggressive about caching things out to disk.
Listen to the OS-provided notifications that your memory is under pressure.
Design your app in such a way that you can restore its last UI state from fresh launch: app launches and task switches are presented to the user the same way, and they won't and shouldn't need to know the difference.
If you do use more and more memory, the OS will try and terminate other apps to make room for yours. That means, bye bye Facebook, bye bye Twitter, bye bye Mail, bye bye Contacts. Your users will notice, and they will choose to launch your app less often, or review it less favorably, as a result.
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".