Database Info

WTF is "0" in my battery history

I've had this on other android devices before but never this bad. Under network usage, the top item is consistently "0". Clicking on it results in FC. I just went to CM7. I dont think the issue came back until I reinstalled all of my apps. I used a network monitor when I was stock rooted and never saw anything unusual. Anyone have any ideas? I have a feeling it is killing my battery.
Sent from my LG-P999 using Tapatalk

Bump. I have the same issue. If I click on the item labeled 0, it force closes.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Sent from my LG-P999 using XDA App

arcanumal said:
Bump. I have the same issue. If I click on the item labeled 0, it force closes.
Sent from my LG-P999 using XDA App
Click to expand...
Click to collapse
Can you give me a list of all of your apps? Maybe we have a culprit in common.

Bump.......
Sent from my LG-P999 using Tapatalk

I have the same. I believe it is all non system apps lumped together as I don't have any of them listed like I did on my n1. I think the system isn't representative of individual app use for data or battery. The battery history normally lists apps associated with a specific uid if you press each. My theory is something in the framework isn't registering apps independently but grouping them together creating false readouts.
[EDIT] I do see individual apps on network use so I want to strike my theory. Now I'm just back to puzzled.
Sent from my T-Mobile G2x using XDA App

seems like mine but mine stopped a 999% battery left and i was like wtf?

hah2110 said:
Can you give me a list of all of your apps? Maybe we have a culprit in common.
Click to expand...
Click to collapse
Sorry, been too busy to check back in on XDA for a few days. I could post a list of apps, but my original observation was during the couple of days after I did all the factory wiping / calibrating to fix my battery life. I didn't have any non-stock apps installed at the time.
The 0 is still there, and still force closes. I was hoping some more people might have insight on this, but it doesn't seem to have caught on.

Bunko
Sent from my LG-P999 using Tapatalk

[Q] Thread-xxxx consuming RAM

I was checking what apps consumes RAM from my galaxy nexus (running android 4.3, franco kernel), as there was a case when my available RAM went down to as low as 2MB!! So as expected, almost all applications get killed after removing them from foreground (including Launcher).
I checked System Monitor, and there were "apps" named Thread-xxxx consuming RAM. At one time, I noticed they were consuming around 80+MB to 90+MB. In the screenshot I attached, there are three Thread-xxx consuming around 50+MB each.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Can anyone explain what are they for? They are not apps that can be "force closed", tapping on them doesn't do anything in system monitor.
They seem to free their consumed RAM after restart. So if I'm running out of RAM, i only need to restart my phone. Any other way to free their RAM without restarting?
Please tell me what other info I need to provide.. Thanks!

By the way, these Thread-xxxx processes appears only when the option "Show system processes" is checked.
I was again able to get a screenshot with those processes consuming RAM. Can't seem to find a way to free ram other than reboot.
Sent from my Galaxy Nexus using Tapatalk 4

garuhhh said:
I checked System Monitor, and there were "apps" named Thread-xxxx consuming RAM. At one time, I noticed they were consuming around 80+MB to 90+MB. In the screenshot I attached, there are three Thread-xxx consuming around 50+MB each.
Click to expand...
Click to collapse
How to handle threads in Android, and what you need to watch for
Processes and Threads

immortalneo said:
How to handle threads in Android, and what you need to watch for
Processes and Threads
Click to expand...
Click to collapse
Thanks for taking time to reply,
but I need to know, on a user perspective, how do I kill those threads?
I'm not doing any app development.

I was trying to see whether one app is causing this problem. The first one I checked is Skype.
I didn't turn it on for 2 to 3 days, and no Sign of those Thread processes.. Until I made a video call with Hangouts, immediately after the video conference these Thread processes showed up again. See the attachment. It started with only one (the 70MB) then this morning there were two of them.
Sent from my Galaxy Nexus using Tapatalk 4

I tried going back to Stock Kernel to see whether I'll see any RAM problems, but after almost a week of using stock kernel, I haven't experienced any of these problems. But i miss my good battery life with this kernel..
by the way, after reboot, I don't have these Thread-xxx processes, but after a few hours they start to show up (see the attached image). They're all 20+ processes. Although right now they don't consume RAM yet.
I hope somebody can give me a hint as to what these are. Googling is no use. Or at least a good keyword to use will also be fine.
Sent from my Galaxy Nexus using Tapatalk 4

Anyone using the optimized Dalvik?

I decided to try it out just to see how well it works by comparing benchmarks. Turns out, it works well.
Without:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
With:
Sent from my One X using xda app-developers app

magnetboard said:
I decided to try it out just to see how well it works by comparing benchmarks. Turns out, it works well.
Without:
View attachment 2491843
With:
View attachment 2491844
Sent from my One X using xda app-developers app
Click to expand...
Click to collapse
do u mean ART? android run time... good scores if you are on stock!
if so i dont think it can be called optimized dalvik cause dalvik refers to the dalvik virtual machine of java.

Are you talking about ART or the Qualcomm Dalvik?
Sent from my HTC One XL using Tapatalk

I think he's talking about ART but has just misidentified the terminology.
Sent from my Evita

No, the Qualcomm optimized dalvik. I'll post a link in a minute.
Edit: here is the thread. http://forum.xda-developers.com/showthread.php?t=2546120
Just follow the instructions and you should be fine. I only flashed the dalvik as I'm on beanstalk 4.4
Sent from my One X using xda app-developers app

Excuse my ignorance but does that mean the benchmark program (Antutu) uses non native code. Isn't that counter intuitive for a benchmarking app?
Or does absolutely everything on Android use the Dalvik VM.

Android uses dalvik by default. On kitkat, you can enable ART and that uses the naive code stuff. My guess is that ART boosts benchmarks by loading the code a bit faster as it is ready to be launched.
Sent from my One X using xda app-developers app

Tested both ART & Dalvik opt + bionic .
I prefer ART , runs much smooth.

[Q]Google Dialer Keeps Phone Awake

I have noticed one of my biggest battery draining apps is the google dialer application.
For some reason it seems to keep the phone awake for hours on end, even when I do not spend very much time on the phone.
Stock, 4.4.3. rooted, thats it.
Any suggestions or ideas? I've tried clearing the dialer's cache and data, but it still keeps the device awake for no reason it seems.
Thanks in advance!

Anyone? Here are some screen shots.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Sent from my Nexus 5 using Tapatalk

mmh I've never seen that problem.
You could first try clearing data and cache of the app. If that doesn't work, maybe flash the factory images? Just to be sure it's not something on your side.
Hope this helps.
Sent from my Nexus 5 using Tapatalk

Thanks. Tried both of those. No luck .
I re flashed last evening and the bug is still there
Sent from my Nexus 5 using Tapatalk

_jordan_ said:
Thanks. Tried both of those. No luck .
I re flashed last evening and the bug is still there
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
Boot the phone into recovery and then wipe cache and dalvik cache, and then reboot the phone.

I think 4.4.4 addresses this issue, you should make a clean installation of the factory image (again) and see how it goes.
Sent from my Nexus 5 using Tapatalk

raul90 said:
I think 4.4.4 addresses this issue, you should make a clean installation of the factory image (again) and see how it goes.
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
I flashed the 4.4.4 system and radio images.
Will report back. So far so good..... But I will confirm.
Sent from my Nexus 5 using Tapatalk

OK SO i think i MAY have figured out this bug.
I use the search function in the dialer app all the time for work. I call a lot of businesses in the area and i always use the dialer to look up their numbers. This is what I think causes the wakelock, as it triggers a search and looks up local businesses matching the number.
I've turned off this feature in the app, as well as the caller ID function and so far i am not having any issues. Will report back.

Just an update. I can trigger this bug in any ROM, including cyanogen mod and also paranoid android.
Here is the solution until Google offers a fix:
By leaving the above options unchecked, the wake lock will not trigger.
Sent from my Nexus 5 using Tapatalk

Odex or Deodex with ART?

So I'm running ART on a deodexed rom and was thinking of re-odexing sys apps and framework. From what I understand is ART converts Deodexed and Odexed files differently. So what would be the better option? Anybody really knowledgeable on ART?

Well it looks like I may not get an answer but I did some real world testing along with some benchmarks on CM11 and can say without a doubt that ART converts odex better. Why? Not really sure. I don't have the knowledge or the time to really dig into this but an odexed system will still provide a performance improvement thru ART.
If anyone has any insight on the technical reasons as to why this is then please post. It would be interesting.

razz1 said:
Well it looks like I may not get an answer but I did some real world testing along with some benchmarks on CM11 and can say without a doubt that ART converts odex better. Why? Not really sure. I don't have the knowledge or the time to really dig into this but an odexed system will still provide a performance improvement thru ART.
If anyone has any insight on the technical reasons as to why this is then please post. It would be interesting.
Click to expand...
Click to collapse
ART works significantly better because it cuts out the middle man dalvik creates. I read this a while ago so I might not be exactly right, but dalvik uses the dalvik cache to store app information, which in turn opens a second file to initiate the app to open. Adds a delay.
ART is specifically written for Android, while dalvik was originally created for much less of a demanding app environment. ART basically just uses 1 file to control an app, which cuts loading time down and the way apps run. It's just much more efficient.
I wouldn't expect odexing or deodexing to make much of a difference in this scenario.

Well I will say this. After a nice look at a logcat today I found errors of ART trying to identify an odex file (ELF Magic). This pertains to all odex! Just thought I would throw this out there if anyone is interested.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}

This is because ART is looking for compiled native ELF executable, not dalvik runtime. It's completly different format, bacause ELF is java bytecode compiled to native (similar as native .exe on Windows) and ODEX is not. ODEX is compiled as dalvik bytecode that still runs via dalvik VM, not natively.
You should not use .odex on ART.