I've been using android profiler to see how well my application performs on different devices and I was wondering if there's a way to automatically get average values such as average memory consumption in a set amount of time or for the entire duration of the profiling session. Peak values are easy to notice and mark down but an average would be very hard and time consuming to manually determine. I couldn't find any option that would allow me to easily get theses averages for me to make a report on how well my application performs in general.
I've tried searching for any examples on how to do this but haven't been able to find anything similar to what I'm trying to do.
Have you looked into Firebase Performance Monitoring?
Related
Well i have read a lot of answers of similar questions (even if they are old from like 2013-2014) and i understood that it is not possible to know it exactly since android doesnt count the hardware usage as usage of the app, and some other possible problems like services etc.
At the moment I'm trying to test the perfomance of an App using a protocol to reach a goal and the perfomance of the same App using another protocol (not well known by everyone) to reach the same goal, the default android battery analyzer is good for me since both cases are like 90% the same and i know how the protocols work
My problem is that i'm not sure which one is the best to measure the mAph consumed by my App, i know that there are some external apps that shows it but i would prefer using the one of default, I believe this is something important not only for me but for other people who might have to compare different protocols.
I know that i can measure it programmatically and I've done it too, i save the percentage when the app is opened and how much has been consumed until it gets closed, but it isnt an exact measure since while the app is opened some other apps can do heavy work and add some kind of noise of what i'm measuring so i would prefer to use the android's battery analyzer.
Get a spare device. Load it completely, then run the protocol until shutdown without other interaction (no youtube or anything), note the time it lasted. Repeat with the other protocol. Imho that is a fair way to compare. Note that every device behaves differently and it may or may not be possible to transfer this result to other devices e.g. with different network chips, processors or even firmware versions.
For a more fair comparison I think you should compare how the protocols work. I.e. number of interactions, payload size etc. because the power consumption can only ever be an estimate.
I'm writing an app that requires frequent location checks using GPS. It needs to get the current location every 10-15 seconds and then write it to a database (the database part is mostly irrelevant for this question, just wanted to throw it out there). The issue I'm facing is that I can't find a decent way to accomplish this. I've tried several things:
Using LocationManager.getBackgroundLocationListener() never seems to work. I've tried it on both Android and iOS and nothing ever seems to happen. Might be something I'm doing wrong but regardless, I've read that on iOS, it will only get hit when moving to a different cell tower, so that doesn't meet my needs.
I've tried using Background Fetch, but it's only reliable on Android. The frequency is completely random on iOS and so this won't meet my needs either.
I've tried just starting a new thread that will fetch the current location every 10-15 seconds, but this only works when the screen is on and the app is being used. This won't meet my needs because I need to make sure it continues getting location updates when switching to other apps.
Does anyone have any suggestions on alternative methods to solve this problem? Note that I don't have a background in objective-c, so a cross-platform solution like Codename One is really my only option here.
Background fetch isn't the right choice in this case as iOS expects you to declare what you are actually doing. What you are trying to do is prohibited in iOS and might be problematic in Android too.
Fetching location data in the background (especially at this resolution) has serious privacy implications so I doubt it will work. Doing this in the foreground should work fine to allow use cases such as navigation but in the background it might be an issue.
This is further compounded by the fact that location and networking are big battery draining activities. So there are limits to the resolution you can apply with these API's. One of the more common use cases for background is geo-fencing which allows you to track when a user approaches an important point of interest. The reason this API exists is to reduce polling costs and keep location usage to a minimum.
Notice that both Android & iOS provide tools to detect battery usage for the user and these might impact misbehaving apps.
Often I'm making some small changes, within one file, not touching 99% of the code. For example: small refactoring, tweaking parameters, layouts, animations. Changes which take couple of seconds. I just want to quickly experiment with many options and see what is the best.
There is a huge problem - recompilation and deploying time. I waste my time and lose my focus, which dramatically increases total tweaking time - from seconds of actual work to minutes (hours?), because of waiting and constant distractions. It's also annoying and doesn't encourage to experiment more.
I've heard about DyCI - Dynamic Code Injection, which does exactly what I want - "change your code and see the results right away". But, it's for iOS.
Is it possible to change the code and see the results right away on Android? How?
You could use incremental dex-ing
Full Incremental Builds – The new Gradle-based Android build system
has been designed for developer efficiency. Gradle’s support for
incremental tasks means you spend less time waiting and more time
coding.
from https://www.gradleware.com/android/gradle-the-new-android-build-system/
Also
What does the "Incremental Dex" option in Android Studio do?
If you're talking about hotswap, I think it's not possible with Dalvik VM (android's java virtual machine). This answer tells it too
Well i have successfully obtained the light value, however, it is EXTREMELY delayed. Approx 3~5 seconds even when using .SENSOR_DELAYED_FASTEST also even when entering 0 as the rate. Its so slow. I have the program check light sensor values upon screen on then change brightness accordingly HOPING it would solve the horrible automatic brightness delay. but after messing around with it, it seems to me that this is simply a flaw in android. It simply cannot update fast enough. I have used getDefaultSensor() but according to android documention this value can be delayed/filtered, but upon reading another post on stackoverflow the getSensorList() and getDefaultSensor() return the same values and that getSensorList() is no different than getDefaultSensor()
The reason for my question is: Is this correct? Is android simply a fail at updating immediatly? its funny cause my Windows MOBILE(not phone) can update immediatly and i loved it. but with all android devices ive seen its the same thing. so is this just a flaw in androids programming? Is there a way for me as an app dev to fix this? or do we have to live with it?
As I know you cannot get it faster. Please take a look on this question and answer: https://stackoverflow.com/a/5060690/1381641
I don't have the solution for your problem, but I do have an explanation for it. The Ambient light sensor has a delay because of the integration time downloads Sensor Box for android from the Playstore.
You will get the hardware ID of your ambient light sensor, then google search it, and you will get a PDF with technical details about that specific model number. Every Android or IOS phone does NOT use the same hardware.
In that PDF, you will get an integration time. It exists to keep the brightness control stable and delayed as well as sensible. If it is low, and you are in a disco your brightness level will keep on flickering. The same for outside, sometimes some shadows make it go up and down if the integration time is low. It will flicker more and will not be stable.
This will also cause harm to the backlight, so instead of taking single values they compile down the values of a big time interval. My integration time was 400ms. This value is sent to the processor, and then the decision is taken.
You could change this value. It is easy, AMD hard boh depends on your expertise like to update this you have to program the ALS unit by opening the phone, connecting a programmer to it, and connecting the pins in the right way. Then sending an 8 bit signal as mentioned in the PDF (if model is programmable).
I'm developing an Android app which needs to download a lot of data.
To improve the usability, I'd like to measure the data traffic my app produces and give the users a hint if the app downloaded a specific amount of data.
My current idea: Sum all downloaded bytes together and react on a specified limit. However, as I downloaded things in many different situations and in many different positions in the code, is there any other possibility to measure the data usage per app?
AFAIK, sys/net/NETINTERFACE/statistics/rx_bytes reports the total amount of the whole system, so this is not a solution.
However, as I downloaded things in many different situations and in many different positions in the code, is there any other possiblity to measure the data usage per app?
TrafficStats may be able to report things by UID. I say "may" because it seems tied to devices. I suspect that Android 3.0+ will consistently report by UID, but my 2.2 and 2.3 experience has been mixed.
Here is a sample application demonstrating recording this information.