AndroidIDEOfficial
[Bug]: battery drain
What happened?
In this latest version 2.5.0-beta, my device gets very hot when using AndroidIDE, causing unusual battery consumption. my device is a Galaxy S20 fe Android 13 6GB RAM
What's the expected behavior?
that the device does not heat up while using the application.
What version of AndroidIDE you're using?
v2.4.0 (debug builds)
Relevant log output
No response
Duplicate issues
- [X] This issue has not been reported yet.
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
if your project is big it sure will gonna consume a lot of memory and processing power, so its normal.
if your project is big it sure will gonna consume a lot of memory and processing power, so its normal.
no, it has been happening with any project, besides that in previous versions it did not happen.
if your project is big it sure will gonna consume a lot of memory and processing power, so its normal.
no, it has been happening with any project, besides that in previous versions it did not happen.
try disabling diagnostics in the editor settings
if your project is big it sure will gonna consume a lot of memory and processing power, so its normal.
no, it has been happening with any project, besides that in previous versions it did not happen.
try disabling diagnostics in the editor settings
I'll do that, I'll tell you if I got results.
This issue is real. I had to revert back to version v2.4.1-beta because of it.
I think it has something to do with the log sender/receiver, which were not built-in in version 2.4.1.
As I have observed, after opening the IDE, usage is fine (I think?) without heating up. However, as soon as we open and run a debug-app, the device starts to heat up from there, even after the debug-app has been completely closed. From the IDE, every time we start a debug-app, the number of clients keeps going up and never released. The CPU usage is at max (I observed) until we close the project and exit (not suspend) the IDE. Version 2.5.0 had continuous error messages in the app log. Version 2.5.1 made it stop but the max CPU usage and heating up problem is still there.
One of the messages above says it is expected that it gets warm and drains battery for such a capable IDE, but no, it should not. If all we do is scroll through the source code and build apps that don't take too long to build, the device should not heat up or drain the battery more than ussual (even if we are coding for hours.)
@itsaky May I request a quick fix release that has an option to activate/deactivate the log sender/receiver on-the-fly, until the problem is fixed?
Este problema es real. Tuve que volver a la versión v2.4.1-beta por eso.
Creo que tiene algo que ver con el remitente/receptor de registros, que no estaban integrados en la versión 2.4.1.
Como he observado, después de abrir el IDE, el uso está bien (¿creo?) Sin calentarse. Sin embargo, tan pronto como abrimos y ejecutamos una aplicación de depuración, el dispositivo comienza a calentarse desde allí, incluso después de que la aplicación de depuración se haya cerrado por completo. Desde el IDE, cada vez que iniciamos una aplicación de depuración, la cantidad de clientes sigue aumentando y nunca se libera. El uso de la CPU está al máximo (observé) hasta que cerramos el proyecto y salimos (no suspendemos) del IDE. La versión 2.5.0 tenía mensajes de error continuos en el registro de la aplicación. La versión 2.5.1 hizo que se detuviera, pero el uso máximo de CPU y el problema de calentamiento siguen ahí.
Uno de los mensajes anteriores dice que se espera que se caliente y agote la batería para un IDE tan capaz, pero no, no debería. Si todo lo que hacemos es desplazarnos por el código fuente y crear aplicaciones que no tarden demasiado en crearse, el dispositivo no debería calentarse ni agotar la batería más de lo normal (incluso si estamos programando durante horas).
¿Puedo solicitar una liberación rápida que tenga una opción para activar/desactivar el remitente/receptor de registro sobre la marcha, hasta que se solucione el problema?
Yes, I've already tried deactivating the diagnostic, creating a new project to see if it's a problem with the size of my project and it's still the same, the CPU usage is intense, I also realized that it was caused by the Log Sender
I'll look into the issue.
@itsaky May I request a quick fix release that has an option to activate/deactivate the log sender/receiver on-the-fly, until the problem is fixed?
There is a method to disable the logsender service, but it was never tested and hence, undocumented.
Have a look at this line. The logsender_enabled boolean resource is used to enable/disable the LogSenderInstaller. As a workaround, you can try to override this boolean resource in your project which should disable the installer.
I'll look into the issue.
@itsaky May I request a quick fix release that has an option to activate/deactivate the log sender/receiver on-the-fly, until the problem is fixed?
There is a method to disable the logsender service, but it was never tested and hence, undocumented.
Have a look at this line. The
logsender_enabledboolean resource is used to enable/disable theLogSenderInstaller. As a workaround, you can try to override this boolean resource in your project which should disable the installer.
I will be testing for the whole day today and I will tell you the results obtained. thank you
I'll look into the issue.
@itsaky May I request a quick fix release that has an option to activate/deactivate the log sender/receiver on-the-fly, until the problem is fixed?
There is a method to disable the logsender service, but it was never tested and hence, undocumented.
Have a look at this line. The
logsender_enabledboolean resource is used to enable/disable theLogSenderInstaller. As a workaround, you can try to override this boolean resource in your project which should disable the installer.
hello dev, I can confirm that it is LogSender that is causing the high processor usage, I did what you recommended and my device doesn't get hot anymore. Greetings, I hope with a solution.
@esalessandrxx Can you test the implementation again with this build?
Yes, I will test and I will tell you the results obtained.
@esalessandrxx Can you test the implementation again with this build?
Yes, I will test and I will tell you the results obtained.
I forgot to mention that after you install this build, you'll have to rebuild and install your application. There have been significant changes in the logsender API.
@itsaky I have been using AndroidIDE for 4 hours, so far my device has not warmed up and logsender is working fine. It seems that the error has been fixed.
@itsaky I have been using AndroidIDE for 4 hours, so far my device has not warmed up and logsender is working fine. It seems that the error has been fixed.
@itsaky then close this issue
As of v2.5.3-beta, I think the battery/heat problem is still there. Maybe not as apparent as before but it could still happen when we don't pay attention.
I was using the IDE as before, running the debug app, closing the debug app, then switching back to the home screen and going to sleep, thinking the problem had been fixed. In the morning, I found the battery had gone down more than 20 percents and warm. I looked at the CPU usage and it was high. I switched to the IDE, closed the project, and exited the IDE. The CPU went down and battery started to cool off.
Personally, it has been solved for me, I rarely close AndroidIDE, it is always in the background and when using the battery it only appears in the foreground, that is, when I use it.
As of v2.5.3-beta, I think the battery/heat problem is still there. Maybe not as apparent as before but it could still happen when we don't pay attention.
I was using the IDE as before, running the debug app, closing the debug app, then switching back to the home screen and going to sleep, thinking the problem had been fixed. In the morning, I found the battery had gone down more than 20 percents and warm. I looked at the CPU usage and it was high. I switched to the IDE, closed the project, and exited the IDE. The CPU went down and battery started to cool off.
who in the right mind would just keep an application running for the whole night in the background without exiting the app properly? i'm sure that's because the gradle daemon keep running for the whole night
who in the right mind would just keep an application running for the whole night in the background without exiting the app properly? i'm sure that's because the gradle daemon keep running for the whole night
Please be polite, follow the Code of Conduct.
And yeah, maybe keeping the Gradle Daemon running for that much time is not a good idea. But still, if AndroidIDE heats up the device even when it is idle in the background for a few hours, that's an issue (at least for small to medium sized projects).
who in the right mind would just keep an application running for the whole night in the background without exiting the app properly? i'm sure that's because the gradle daemon keep running for the whole night
Well, before the heating problem was introduced, that was how I always use the phone. AndroidIDE (or any other apps I have) never had the heating problem with that. It could be backed up by the fact that the CPU always went back to normal after I went back to home for all the apps that I had including AndroidIDE (v2.4.0 and earlier). I always pay attention to intense tasks such as file compression and know if they are running and make sure they are done.
A background service does NOT always mean high intense CPU usage. A properly handled background service knows when it should be idled and would only affect the battery minimally.
i'm sure that's because the gradle daemon keep running for the whole night
And yeah, maybe keeping the Gradle Daemon running for that much time is not a good idea.
If, and only if, the Daemon is actively running and processing. This seems not to be the case.
@itsaky With all the recent commits following 2.5.3-beta involving the log sender/receiver, maybe you are already aware of the issue. My posted confirmation that it could still happen might not have been needed after all. :)
Thanks for an awesome open-source mobile IDE!
EDIT: I would like clarify that I didn't mean v2.5.3-beta has not improved compared to v2.5.0, v2.5.1, and v2.5.2 regarding the heat/battery issue. Before, it always happened. Now, it just happens under some conditions.
I think I found one of the cases when the issue can still happen. There could be other cases.
If a debug-app is buggy and somehow not closing down properly even after swiping it off the current apps list (A manual force close from the app's properties would probably do it but we don't usually do this since it's a little inconvenient), it would cause the client to still linger around and cause the heat/battery issue.
In this case, we just might be quick to blame on the debug-app and say, "Well, it's not the IDE's fault." But hey, it's a debugging feature for debugging buggy apps. Debug-apps are inclined to be buggy :)
So, for now, as a reminder for anyone who is mindful of this issue, before switching back to home screen and put the device away, just make sure the most recent line for client count in the IDE logs says (0).
@itsaky Along with some of the recent commits regarding the log sender/receiver, do you think we could also add a reminder message of some sort when the IDE is pausing, that there are still some debugging clients connected? Maybe even on the notification area?
If a debug-app is buggy and somehow not closing down properly even after swiping it off the current apps list.
If you remove the app from the recents app list, the system is expected to notify about this event to the service (docs). This is handled by the LogSenderService. Can you send the sample/buggy application you're talking about?
Along with some of the recent commits regarding the log sender/receiver, do you think we could also add a reminder message of some sort when the IDE is pausing, that there are still some debugging clients connected? Maybe even on the notification area?
Sure, we could do this. But currently I have other tasks to do (I'm building the terminal packages and build/platform-tools v34.0.x).
If you remove the app from the recents app list, the system is expected to notify about this event to the service (docs). This is handled by the LogSenderService. Can you send the sample/buggy application you're talking about?
I have changed a lot in my code since then, and couldn't seem to get back to the state in which it happened.
However, after a long time testing, I think it likely happens when the debug-app crashes under certain conditions and somehow skips some system default handling.
I have tried to use System.exit(0) to make an abrupt exit thinking that it somehow would be able to simulate a crashing condition. It indeed caused the client to hang around (I could only guess that it did by the fact that there was no message saying client count was back to 0, and CPU usage was intense from home screen) even after I swiped it off the recent task list. Maybe you could setup any sample project and do the same and observe the results.