When I try to turn on wifi it says turning on wifi, than "connect" and than -"unable to scan for networks", sometimes with message "Application Settings (in process com-android-settings) is not responding" and disables wifi.
When I bought my used n1 the guy that sell it to me said that he's rooted it and flashed Cyanogen and wifi stoped connect. After that he flashed it with Froyo FRF50 and WiFi worked again. About week ago WiFi stopped working again. I tried to flash new radio (it was on old radio and froyo before that), several wipes, factory resets, flashing original shipping rom + kernel/boot image (not removed recovery and radio still was 4.06(?)), flashing froyo that worked before (frf50, he left it on the card, so it's the same one that worked for him), flashing frf91 - no change - wifi still not working..
I'm with Baseband ver. 32.36.00.28U_4.06.00.12_7
Kernel ver. 2.6.32.9.-27220-g328f560 android-build(a)apa26 #1
now with froyo FRF50
Please help me with that! No idea what else can I do to make it work..
some additional desperate steps -
updated to kernel 2.6.34 from Cyanogen - same problem
factory reset + wipe everything + factory rom & recovery >>> OTA update to FRF91 - still same problem..
HELP PLEASE!!!
logcat:
E/wpa_supplicant( 1152): Failed to disable WPA in the driver.
D/WifiStateTracker( 82): Reset connections and stopping DHCP
W/ActivityManager( 82): Timeout of broadcast BroadcastRecord{44c77b38 android.
net.wifi.WIFI_STATE_CHANGED} - [email protected]
W/ActivityManager( 82): Receiver during timeout: ResolveInfo{44c777d8 com.andr
oid.settings.widget.SettingsAppWidgetProvider p=0 o=0 m=0x108000}
........
E/ActivityManager( 82): Reason: Broadcast of Intent { act=android.net.wifi.WIF
I_STATE_CHANGED flg=0x10000000 cmp=com.android.settings/.widget.SettingsAppWidge
tProvider (has extras) }
E/ActivityManager( 82): Load: 1.36 / 1.23 / 1.01
E/ActivityManager( 82): CPU usage from 129545ms to 26ms ago:
E/ActivityManager( 82): system_server: 4% = 3% user + 1% kernel / faults: 21
38 minor
E/ActivityManager( 82): droid.wallpaper: 4% = 3% user + 0% kernel / faults:
3053 minor
E/ActivityManager( 82): akmd: 1% = 0% user + 1% kernel / faults: 74 minor
E/ActivityManager( 82): ndroid.settings: 0% = 0% user + 0% kernel / faults:
43 minor
E/ActivityManager( 82): m.android.phone: 0% = 0% user + 0% kernel / faults:
18 minor
E/ActivityManager( 82): events/0: 0% = 0% user + 0% kernel
E/ActivityManager( 82): e.process.gapps: 0% = 0% user + 0% kernel / faults:
104 minor
E/ActivityManager( 82): droid.launcher2: 0% = 0% user + 0% kernel / faults:
57 minor
E/ActivityManager( 82): kmmcd: 0% = 0% user + 0% kernel
E/ActivityManager( 82): viders.calendar: 0% = 0% user + 0% kernel / faults:
44 minor
E/ActivityManager( 82): oid.voicesearch: 0% = 0% user + 0% kernel / faults:
56 minor
E/ActivityManager( 82): suspend: 0% = 0% user + 0% kernel
E/ActivityManager( 82): adbd: 0% = 0% user + 0% kernel / faults: 15 minor
E/ActivityManager( 82): init: 0% = 0% user + 0% kernel / faults: 3 minor
E/ActivityManager( 82): ds2784-battery: 0% = 0% user + 0% kernel
E/ActivityManager( 82): usb_mass_storag: 0% = 0% user + 0% kernel
E/ActivityManager( 82): synaptics_wq: 0% = 0% user + 0% kernel
E/ActivityManager( 82): rild: 0% = 0% user + 0% kernel
E/ActivityManager( 82): android.vending: 0% = 0% user + 0% kernel / faults:
7 minor
E/ActivityManager( 82): equicksearchbox: 0% = 0% user + 0% kernel / faults:
8 minor
E/ActivityManager( 82): d.process.media: 0% = 0% user + 0% kernel / faults:
20 minor
E/ActivityManager( 82): ogle.android.gm: 0% = 0% user + 0% kernel / faults:
11 minor
E/ActivityManager( 82): com.android.mms: 0% = 0% user + 0% kernel / faults:
8 minor
E/ActivityManager( 82): timeinitializer: 0% = 0% user + 0% kernel / faults:
7 minor
E/ActivityManager( 82): oid.voicedialer: 0% = 0% user + 0% kernel / faults:
7 minor
E/ActivityManager( 82): com.amazon.mp3: 0% = 0% user + 0% kernel / faults: 1
4 minor
E/ActivityManager( 82): pps.googlevoice: 0% = 0% user + 0% kernel / faults:
13 minor
E/ActivityManager( 82): nie.geniewidget: 0% = 0% user + 0% kernel / faults:
14 minor
E/ActivityManager( 82): d.process.acore: 0% = 0% user + 0% kernel / faults:
11 minor
E/ActivityManager( 82): flush-31:0: 0% = 0% user + 0% kernel
E/ActivityManager( 82): +logcat: 0% = 0% user + 0% kernel
E/ActivityManager( 82): +logcat: 0% = 0% user + 0% kernel
E/ActivityManager( 82): TOTAL: 13% = 8% user + 5% kernel
D/WifiService( 82): releaseWifiLockLocked: WifiLock{NetworkLocationProvider ty
pe=2 [email protected]}
D/WifiStateTracker( 82): Disabling interface
W/ActivityManager( 82): finishReceiver called but no pending broadcasts
E/WifiHW ( 82): Supplicant not running, cannot connect
D/dalvikvm( 509): GC_EXPLICIT freed 58 objects / 2880 bytes in 71ms
W/InputManagerService( 82): Window already focused, ignoring focus gain of: co
[email protected]
E/WifiHW ( 82): Supplicant not running, cannot connect
E/WifiHW ( 82): Supplicant not running, cannot connect
V/WifiStateTracker( 82): Supplicant died unexpectedly
D/WifiStateTracker( 82): Reset connections and stopping DHCP
D/WifiStateTracker( 82): Disabling interface
D/NetworkStateTracker( 82): setDetailed state, old =DISCONNECTED and new state
=DISCONNECTED
D/WifiStateTracker( 82): Reset connections and stopping DHCP
D/WifiStateTracker( 82): Disabling interface
I am seeing similar behavior on my Nexus 7 as I did on my other tablet: http://forum.xda-developers.com/showthread.php?t=2155609
Would it be fair to conclude that a recent Google component update (Maps? Gmail?) is causing this tablet to remain awake?
Maybe. Maybe not.
Could be one of your market apps too.
Seem like you need to discover what is holding the wake locks.
Here's a start (if you are rooted)
Code:
$ su
# strings /data/system/packages.xml | awk '/<package name=/{n=$2;}/WAKE_LOCK/{print n;}'
wouldn't it be a kick in the pants if you found out it was the battery monitoring apps
good luck
I have su, but no awk or strings. Where did you get those linux utilities? I've been wanting a full set of those.
I'll copy packages.xml to my Linux box and try it out.
Thanks.
Using the CT702 tablet -
How does this:
{
"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"
}
correlate with this (output from your script):
name="com.kiloo.subwaysurf"
name="com.snrblabs.grooveip"
name="com.amazon.venezia"
name="com.skype.raider"
name="com.keramidas.TitaniumBackup"
name="com.kiwi.shipwrecked"
name="com.dropbox.android"
name="com.estrongs.android.taskmanager"
name="com.google.android.apps. genie.geniewidget"
name="com.netflix.mediaclient"
name="com.google.android.gm"
name="com.estrongs.android.pop"
name="com.metago.astro"
name="jp.co.johospace.jorte"
name="com.lsdroid.cerberus"
name="com.google.android.apps.googlevoice"
name="com.android.phasebeam"
name="com.android.phasebeam"
name="com.android.phasebeam"
name="com.android.phasebeam"
name="com.android.phasebeam"
name="com.android.phasebeam"
name="com.android.phasebeam"
name="com.android.phasebeam"
my phone too used to stay awake when i wasnt using it the solution being get a task manager and killl all unused apps also gps when not in use
I guess my original point was that you'll find both system and market apps that hold wake locks. (BTW your web browser should be able to display that packages.xml file if you want to have a look in it)
Well, I don't know for sure, but that image you attached sure seems to implicate Maps.
The thing is - and it's one of the things that sort of sucks about android - is that it is difficult to filter broadcast receivers. So, apps can spring back to life even if you've manually killed them if a separate app generates a matching broadcast that the former has registered for.
Some market apps are greedy in this regard - they register for all sorts of broadcasts so an appearance is maintained that they open quickly - on the off chance that a user will be sharing data between the app currently in use and that (other market) app.
In prior versions of Android, lots of apps - both system and market apps - would register as broadcast receivers for certain events produced by the stock email app. If you browsed the inbox, no problem... but as soon as you open an individual email, a whole slew of apps would get launched in the background.
Anyway - and this is a hypothesis - even if Maps is preventing sleep by holding wake locks, it could be a different app that is causing it to spring to life - or even a rather obscure startup cycle that depends on both market apps and/or system apps before Maps finally gets restarted.
If you manually kill off Maps and then shut the screen off, and then come back some time later and find Maps running again, you should be able to observe the event that restarts Maps in the logcat output.
good luck
---------- Post added at 10:58 PM ---------- Previous post was at 10:45 PM ----------
Nate2 said:
I have su, but no awk or strings. Where did you get those linux utilities? I've been wanting a full set of those.
I'll copy packages.xml to my Linux box and try it out.
Thanks.
Click to expand...
Click to collapse
Whoop - sorry. I was using BTEP (Better Terminal Emulator Pro) which comes with it's own private busybox (not installed in /system)
You could also install a busybox flash, but I would recommend you use one that doesn't touch /system/bin or /system/xbin. (I think at least on of the market versions might refer to this as a "safe install") I'm not familiar with them, so I can't recommend a particular version.
Right you are, sir!
I stopped Maps at 19:36, and exactly 1 hour later at 20:36, it re-started itself:
02-23 19:36:57.740 1121 1133 I ActivityManager: Killing proc 5340:com.google.android.apps.maps/10070: kill background
...
02-23 20:36:22.210 1121 1152 I ActivityManager: Start proc com.google.android.apps.maps for service com.google.android.apps.maps/com.google.googlenav.prefetch.android.PrefetcherService: pid=6033 uid=10070 gids={3003, 1015}
I can't find what app (if any) might have caused that. pid=6033 looks all Maps-related, not 3rd party.
Not sure myself either.
That logcat message looks a little different than an intent sent from a different app.
I suppose you have some more digging to do.
Sorry I'm not more help - my N7 rarely leaves the house, so if it's not in use it is on the charger. The consequence of that is that I have no idea whether it fails to sleep or not; I certainly wouldn't know from looking at the battery charge state/history anyway.
Don't know how helpful this is, but if the N7 does go into deep sleep, you will see messages in the kernel log (dmesg or /proc/kmsg) about entering the LP0 state.
Tedious to correlate those messages with logcat though - I think those messages are reported in seconds since boot rather than GMT or local time ... and worse yet that timestamp seem to get screwed up by LP0 sleep. (LP0 is a very deep sleep - the SoC is very nearly off completely - even the memory controller is turned off)
good luck
have you tried using better battery stats from this thread? It's a great app, and is also available on the play store if you want to donate to the dev.
just let it run for a while and post screenshots of kernel wakelocks, partial wakelocks, and alarms
Trying the XDA version now...
I think I've identified the problem on the CT702 tablet now; the problem on the Nexus 7 is still under investigation (not the same problem).
CT702 is not always awake now:
Google Maps is still the problem:
Better Battery Stats identifies Maps components responsible?
I've turned off these options in Google Maps to enable the tablet to sleep better:
Hopefully, the above will help someone. My Nexus 7 is being kept awake by SystemUpdateService.
More to follow..
Nate2 said:
I think I've identified the problem on the CT702 tablet now; the problem on the Nexus 7 is still under investigation (not the same problem).
CT702 is not always awake now:
View attachment 1762570
Google Maps is still the problem:
View attachment 1762572
Better Battery Stats identifies Maps components responsible?
View attachment 1762575
I've turned off these options in Google Maps to enable the tablet to sleep better:
View attachment 1762577
Hopefully, the above will help someone. My Nexus 7 is being kept awake by SystemUpdateService.
More to follow..
Click to expand...
Click to collapse
2 minutes of wakelocks over 23 hours isn't much. are there kernel wakelocks? the alarms don't seem to be too much either..
CT702:
===================
General Information
===================
BetterBatteryStats version: 1.12.0.0RC11
Creation Date: 2013-02-25 08:11:40
Statistic Type: Boot to Current
Since 10 h 51 m 13 s
VERSION.RELEASE: 4.0.3
BRAND: Android
DEVICE: m805_892x
MANUFACTURER: YG
MODEL: A777
OS.VERSION: 3.0.8-tcc
BOOTLOADER: unknown
HARDWARE: m805_892x
FINGERPRINT: unknown
ID: A777
TAGS: test-keys
USER: root
PRODUCT: full_m805_892x_evm
RADIO:
Rooted: true
============
Battery Info
============
Level lost [%]: 21 Bat.: 21% (98% to 77%) [1.9%/h]
Voltage lost [mV]: 56 (3889-3833) [5.2%/h]
===========
Other Usage
===========
Deep Sleep (): 10 h 36 m 10 s (38170 s) Ratio: 97.6%
Awake (): 15 m 2 s (902 s) Ratio: 2.3%
Screen On (): 11 m 46 s (706 s) Ratio: 1.8%
Wifi On (): 11 m 45 s (705 s) Ratio: 1.8%
Wifi Running (): 11 m 43 s (703 s) Ratio: 1.8%
No Data Connection (): 10 h 51 m 13 s (39073 s) Ratio: 100.0%
No or Unknown Signal (): 10 h 51 m 13 s (39073 s) Ratio: 100.0%
Screen dark (): 11 m 46 s (706 s) Ratio: 1.8%
=========
Wakelocks
=========
CerberusService (com.lsdroid.cerberus.Cerberus): 1 m 3 s (63 s) Count:1 0.2%
SignalCollector.ScannerThread (com.google.android.apps.maps.Maps): 24 s (24 s) Count:44 0.1%
SignalCollector.Scanner (com.google.android.apps.maps.Maps): 23 s (23 s) Count:110 0.1%
AlarmManager (Android System): 22 s (22 s) Count:184 0.1%
ActivityManager-Launch (Android System): 21 s (21 s) Count:62 0.1%
BBS_WAKELOCK_WHILE_SAVING_REF (com.asksven.betterbatterystats_xdaedition.BetterBatteryStats): 13 s (13 s) Count:10 0.0%
MediaScannerService (Media): 11 s (11 s) Count:2 0.0%
AudioOut_1 (1013): 10 s (10 s) Count:2 0.0%
Event Log Service (Google Services): 6 s (6 s) Count:45 0.0%
maintain LCD off state during 5 second (Android System): 6 s (6 s) Count:63 0.0%
[email protected]/android_talk123456789cb0 (Google Services): 4 s (4 s) Count:3 0.0%
*sync*_com.android.calendar_Account {[email protected], type=com.google} (com.google.android.calendar.Calendar): 3 s (3 s) Count:4 0.0%
*sync*_gmail-ls_Account {[email protected], type=com.google} (com.google.android.gm.Gmail): 2 s (2 s) Count:2 0.0%
NetworkLocationLocator (com.google.android.apps.maps.Maps): 2 s (2 s) Count:2 0.0%
GTALK_ASYNC_CONN_com.google.android.gsf.gtalkservice.AndroidEndpoint (Google Services): 2 s (2 s) Count:6 0.0%
NetworkLocationCallbackRunner (com.google.android.apps.maps.Maps): 1 s (1 s) Count:30 0.0%
WifiStateMachine (Android System): 1 s (1 s) Count:94 0.0%
Checkin Service (Google Services): 1 s (1 s) Count:20 0.0%
AsyncCollectorListener (com.google.android.apps.maps.Maps): 1 s (1 s) Count:96 0.0%
SCREEN_FROZEN (Android System): 1 s (1 s) Count:76 0.0%
sleep_broadcast (Android System): 1 s (1 s) Count:74 0.0%
*backup* (Android System): 1 s (1 s) Count:97 0.0%
================
Kernel Wakelocks
================
"PowerManagerService" (): 1 m 22 s (82 s) Cntc/wc/ec)152/0/0 0.2%
"alarm_rtc" (): 38 s (38 s) Cntc/wc/ec)73/73/0 0.1%
"alarm" (): 14 s (14 s) Cntc/wc/ec)102/1/0 0.0%
"power-supply" (): (0 s) Cntc/wc/ec)335/0/0 0.0%
"KeyEvents" (): (0 s) Cntc/wc/ec)1297/0/0 0.0%
"mmc0_detect" (): (0 s) Cntc/wc/ec)75/0/1 0.0%
======================
Alarms (requires root)
======================
Boot event was not registered yet, it will at next reboot (): Wakeups: 0
======================
Network (requires root)
======================
==========
CPU States
==========
==================
Reference overview
==================
Custom: null
Since charged: null
Since screen off: null
Since unplugged: null
Since boot: Reference ref_boot created 1 m 49 s (Wl: 9 elements; KWl: 0elements; NetS: null; Alrm: null; Proc: 0 elements; Oth: 7 elements; CPU: 0 elements)
Nate2 said:
CT702:
============
Battery Info
============
Level lost [%]: 21 Bat.: 21% ([size=+1]98%[/size] to 77%) [1.9%/h]
Voltage lost [mV]: 56 ([size=+1]3889[/size]-3833) [[size=+1]5.2%/h[/size]]
===========
Other Usage
===========
Deep Sleep (): 10 h 36 m 10 s (38170 s) Ratio: [size=+1]97.6%[/size]
Awake (): 15 m 2 s (902 s) Ratio: 2.3%
Screen On (): 11 m 46 s (706 s) Ratio: 1.8%
Wifi On (): 11 m 45 s (705 s) Ratio: 1.8%
Click to expand...
Click to collapse
I conclude your OS is fine and your battery is bad in the CT702. Perhaps the full cell voltage decreases with age, but what I notice in the above is that it is saying your 98% capacity was only at 3889 mV.
Granted, its not a N7, but I would expect devices using the same battery chemistry to exhibit the same charge voltage range. (Maybe there is more about Li-Ion/Polymer batteries that I need to learn about, too).
The battery in my unit - admittedly only about 8 weeks old - swings between about 3660-4170mv.
That is only a swing of 500 mV for a full discharge cycle - but you are showing less than half of that at a "full charge." I suppose that the full-scale (charged) voltage of the battery pack might decline as it ages, but that seems pretty extreme. Moreover, if you believe the voltage decline statistic, I conclude that whatever made this report thinks that your 100% voltage swing is only 97 mV
( 21% @ 1.9%/hr => 11.1 hrs; 5.2%/hr @ 11.1 hrs => 57%; 56 mV/0.57 = 97 mV)
Those Maps wakelocks are indeed leading the pack - but only in the 2% or so percent of the time that the device is not sleeping. Also - note that 1.9%/hour statistic - when the device is only on about 1.9% of the hour: if it is correct, it would imply that the tablet would fully discharge itself in a single hour if it was on continuously. That certainly can't be the way the tablet is designed to work.
BTW, what app produced this output?
Nate2 said:
Google Maps is still the problem:
View attachment 1762572
Better Battery Stats identifies Maps components responsible?
View attachment 1762575
Click to expand...
Click to collapse
I think that "App Sucker" image is reporting data faithfully, but it's choice of statistic is leading to an unwarranted conclusion - given that the total time wakelocks were held seems to only be two minutes or so out of many hours. That seems to make the assumption that a huge chunk of the battery is used only when wakelocks are held - or that the amount of time the device these locks were held is irrelevant. (Or, to put it another way, would you care if Maps used 73% of the change if the total change was only 5% in 1000 hours?)
BTW, I thought I would tell you about a quick experiment I did the other day. It might help you in your investigation.
I set my tablet aside for about 150 minutes - off the charger, screen off. (This was roughly 10:35am - 1:05pm).
Then I woke it up and captured the kernel log (/proc/kmsg or "dmesg" output) and a logcat. I did this by hand (command line/terminal emulator), so I probably got that done within 2 or 3 minutes.
In the (Stock 4.2.2) kernel log, I see repetitive occurences of entry into LP0 mode: (background on Tegra SoC LPn modes)
Code:
<6>[141548.480341] Entering suspend state LP0
<6>[1415[b][color=red]48.482[/color][/b]222] Tegra: switched to LP cluster
<4>[141548.482430] partition 3d0 is left on before suspend
<4>[141548.482430] partition vde is left on before suspend
<4>[141548.482430] partition heg is left on before suspend
<4>[141548.482430] partition 3d1 is left on before suspend
<6>[1415[b][color=red]48.485[/color][/b]647] Tegra: switched to G cluster
<6>[141548.485791] Exited suspend state LP0
<6>[141548.485921] legacy wake status=0x0
<6>[141548.486145] tegra3 wake status=0x1
<6>[141548.486271] Resume caused by WAKE32, bcmsdh_sdmmc
<6>[1415[b][color=red]48.486[/color][/b]525] Suspended for [b][color=red]597.100 seconds[/color][/b]
<6>[141548.486956] wakeup wake lock: alarm
<6>[141548.492834] PM: early resume of devices complete after 5.636 msecs
Note that the timestamps in this kernel log can not be relied upon - apparently precisely because of the LP0 sleep. I surmise that the kernels' tick counter used for /proc/kmsg logging is suspended and therefore does not accumulate time in a wall-clock fashion; otherwise how could the device sleep for 597 seconds in only 4 milli-seconds?
Having captured the output of "dmesg" into a file "dmesg.txt" (and likewise the logcat into "logcat.txt"), I did a little hand-filtering of the output:
Code:
$ grep 'Tegra: switched to LP' dmesg.txt | wc -l
18
$ grep 'Suspended for' dmesg.txt |wc -l
19
$ grep 'Suspended for' dmesg.txt
<6>[141544.528940] Suspended for 5.813 seconds
<6>[141548.486525] Suspended for 597.100 seconds
<6>[141549.833844] Suspended for 5.610 seconds
<6>[141553.751664] Suspended for 114.785 seconds
<6>[141555.169992] Suspended for 366.895 seconds
<6>[141557.767079] Suspended for 111.202 seconds
<6>[141559.114371] Suspended for 3.868 seconds
<6>[141563.302312] Suspended for 344.820 seconds
<6>[141564.583528] Suspended for 62.516 seconds
<6>[141566.061274] Suspended for 188.582 seconds
<6>[141567.531674] Suspended for 7.695 seconds
<6>[141570.882663] Suspended for 595.651 seconds
<6>[141572.230025] Suspended for 8.666 seconds
<6>[141576.067748] Suspended for 87.744 seconds
<6>[141577.452742] Suspended for 368.048 seconds
<6>[141578.833047] Suspended for 139.359 seconds
<6>[141580.230604] Suspended for 9.878 seconds
<6>[141585.018340] Suspended for 373.786 seconds
<6>[141586.363370] Suspended for 12.157 seconds
$ grep 'Suspended for' dmesg.txt | awk 'BEGIN{s=0;}{s+=0.0+$4;}END{print NR,s;}'
19 3404.18
Now, 3404 seconds is only 3404/(150*60) = 38% of the time of my test... but I just checked and noticed that my kernel log file is exactly 128kB in length - so the kernel log buffer must have rolled over completely during that time, so I really only captured some fraction of the total time of sleep with that log. (The kernel log buffer fills too fast to record that much elapsed time).
But anyway - notice that many of the sleep intervals are several minutes long - once for nearly ten minutes straight!
In comparison, the logcat did capture the entire sleep interval (it had several *days* worth of info in it).
Code:
[l3452:] 02-24 10:35:07.692 481 563 I PowerManagerService: Going to sleep by user request...
[l3453:] 02-24 10:35:08.112 125 169 D SurfaceFlinger: Screen released, type=0 flinger=0x40d12318
...
[l3711:]02-24 13:05:46.952 481 496 I PowerManagerService: Waking up from sleep...
[l3712:] 02-24 13:05:47.222 481 600 D PowerManagerService-JNI: Excessive delay in au\
tosuspend_disable() while turning screen on: 269ms
Or in other words, the logcat capture only had 260 (3712-3452) entries in it for 150 minutes of that elapsed time - less than two entries per minute on average. And there were some notably large gaps. Below are a few excerpts from the logcat which are pairs of immediately adjacent entries in the logcat:
Code:
...
02-24 10:[color=green][b]35[/b][/color]:33.951 585 585 I wpa_supplicant: wlan0: WPA: Group rekeying completed with 00:18:39:cd:99:cb [GTK=CCMP]
02-24 10:[color=red][b]36[/b][/color]:53.731 6683 6683 I RlzPingService: Setting next ping for 1362335813737
...
02-24 10:[color=green][b]37[/b][/color]:00.868 6845 6845 W InvService: Dropping C2DM message for unknown or unstarted client: chromesync#1337300716
02-24 10:[color=red][b]38[/b][/color]:46.241 481 576 D ConnectivityService: Captive portal check NetworkInfo: type: WIFI[], state: CONNECTING/CAPTIVE_PORTAL_CHECK, reason: (unspecified), extra: "notmySSID", roaming: false, failover: false, isAvailable: true
...
02-24 10:[color=green][b]38[/b][/color]:47.261 481 576 D ConnectivityService: NetTransition Wakelock for WifiStateMachine released by timeout
02-24 10:[color=red][b]46[/b][/color]:59.856 913 4117 W Smack/Packet: notify conn break (IOEx), close connection
...
02-24 10:[color=green][b]50[/b][/color]:33.849 585 585 I wpa_supplicant: wlan0: WPA: Group rekeying com\
pleted with 00:18:39:cd:99:cb [GTK=CCMP]
02-24 10:[color=red][b]56[/b][/color]:42.611 913 2062 I EventLogService: Aggregate from 1361730402536 \
(log), 1361730402536 (data)
...
02-24 11:[color=green][b]07[/b][/color]:19.411 481 576 D ConnectivityService: handleInetConditionHoldEnd: net=1, condition=100, published condition=0
02-24 11:[color=red][b]17[/b][/color]:15.824 913 7118 W Smack/Packet: notify conn break (IOEx), close connection
...
Well - anyway : you get the idea - large gaps in time where literally *nothing* is happening. I think you should see the same sort of behavior if your tab is actually sleeping correctly.
bftb0 said:
BTW, what app produced this output?
Click to expand...
Click to collapse
Better Battery Stats - http://forum.xda-developers.com/showthread.php?t=1179809
The "App Sucker" screenshot is from GSAM Battery Monitor - http://play.google.com/store/apps/details?id=com.gsamlabs.bbm
Nexus 7:
===================
General Information
===================
BetterBatteryStats version: 1.12.0.0RC11
Creation Date: 2013-02-25 08:17:25
Statistic Type: Boot to Current
Since 10 h 55 m 33 s
VERSION.RELEASE: 4.1.2
BRAND: google
DEVICE: grouper
MANUFACTURER: asus
MODEL: Nexus 7
OS.VERSION: 3.1.10-g009b6d1
BOOTLOADER: 3.41
HARDWARE: grouper
FINGERPRINT: google/nakasi/grouper:4.1.2/JZO54K/485486:user/release-keys
ID: JZO54K
TAGS: release-keys
USER: android-build
PRODUCT: nakasi
RADIO:
Rooted: true
============
Battery Info
============
Level lost [%]: 1 Bat.: 1% (100% to 99%) [0.1%/h]
Voltage lost [mV]: 0 (4-4) [0.0%/h]
===========
Other Usage
===========
Awake (): 10 h 55 m 33 s (39333 s) Ratio: 100.0%
Screen On (): 12 m 59 s (779 s) Ratio: 2.0%
Wifi On (): 10 h 55 m 33 s (39333 s) Ratio: 100.0%
Wifi Running (): 40 m 18 s (2418 s) Ratio: 6.1%
No Data Connection (): 10 h 55 m 33 s (39333 s) Ratio: 100.0%
No or Unknown Signal (): 10 h 55 m 33 s (39333 s) Ratio: 100.0%
Screen dark (): 12 m 59 s (779 s) Ratio: 2.0%
=========
Wakelocks
=========
SystemUpdateService (Google Services): 10 h 51 m 43 s (39103 s) Count:1 99.4%
AlarmManager (Android System): 45 s (45 s) Count:856 0.1%
[email protected]/android_talk123456789522 (Google Services): 39 s (39 s) Count:5 0.1%
MediaScannerService (Media): 39 s (39 s) Count:2 0.1%
com.zomut.watchdog.MonitorService (com.zomut.watchdog.Watchdog): 38 s (38 s) Count:1308 0.1%
ConnectivityService (Android System): 29 s (29 s) Count:857 0.1%
SignalCollector.ScannerThread (com.google.android.apps.maps.Maps): 17 s (17 s) Count:49 0.0%
SignalCollector.Scanner (com.google.android.apps.maps.Maps): 16 s (16 s) Count:127 0.0%
AlarmManager (com.zomut.watchdog.Watchdog): 9 s (9 s) Count:654 0.0%
NetworkLocationActiveCollector (com.google.android.apps.maps.Maps): 8 s (8 s) Count:51 0.0%
ActivityManager-Launch (Android System): 2 s (2 s) Count:58 0.0%
BBS_WAKELOCK_WHILE_SAVING_REF (com.asksven.betterbatterystats_xdaedition.BetterBatteryStats): 2 s (2 s) Count:5 0.0%
GOOGLE_C2DM (Google Services): 2 s (2 s) Count:26 0.0%
NetworkLocationCallbackRunner (com.google.android.apps.maps.Maps): 1 s (1 s) Count:34 0.0%
NetworkLocationLocator (com.google.android.apps.maps.Maps): 1 s (1 s) Count:2 0.0%
AlarmManager (jp.co.johospace.jorte.Jorte): 1 s (1 s) Count:4 0.0%
NetworkLocationLocator (Google Services): 1 s (1 s) Count:26 0.0%
Event Log Service (Google Services): 1 s (1 s) Count:51 0.0%
WifiStateMachine (Android System): 1 s (1 s) Count:101 0.0%
AudioOut_2 (1013): 1 s (1 s) Count:1 0.0%
================
Kernel Wakelocks
================
"PowerManagerService" (): 10 h 42 m 34 s (38554 s) Cntc/wc/ec)2/0/0 97.9%
"alarm" (): 48 s (48 s) Cntc/wc/ec)1502/0/0 0.1%
"GPS" (): 19 s (19 s) Cntc/wc/ec)2/0/0 0.0%
"power-supply" (): 18 s (18 s) Cntc/wc/ec)656/0/0 0.0%
"wlan_ctrl_wake" (): 16 s (16 s) Cntc/wc/ec)17/0/17 0.0%
"wlan_wake" (): 6 s (6 s) Cntc/wc/ec)3243/0/0 0.0%
"wlan_rx_wake" (): 3 s (3 s) Cntc/wc/ec)57/0/56 0.0%
"KeyEvents" (): 1 s (1 s) Cntc/wc/ec)1571/0/0 0.0%
"event1-351" (system, com.google.android.gm): (0 s) Cntc/wc/ec)2/0/0 0.0%
======================
Alarms (requires root)
======================
Boot event was not registered yet, it will at next reboot (): Wakeups: 0
======================
Network (requires root)
======================
-1 () (Boot event was not registered yet, it will at next reboot): 1.0 Bytes 100.0%
==========
CPU States
==========
51 MHz (): 9 h 32 m 23 s 87.2%
102 MHz (): 9 m 59 s 1.5%
204 MHz (): 7 m 43 s 1.2%
340 MHz (): 56 m 3 s 8.6%
475 MHz (): 4 m 22 s 0.7%
640 MHz (): 2 m 35 s 0.4%
760 MHz (): 6 s 0.0%
860 MHz (): 8 s 0.0%
1 GHz (): 13 s 0.0%
1.1 GHz (): 0.0%
1.2 GHz (): 1 m 41 s 0.3%
1.3 GHz (): 15 s 0.0%
==================
Reference overview
==================
Custom: null
Since charged: null
Since screen off: null
Since unplugged: null
Since boot: Reference ref_boot created 49 s (Wl: 5 elements; KWl: 0elements; NetS: null; Alrm: null; Proc: 0 elements; Oth: 7 elements; CPU: 11 elements)
Looks like maps is the main culprit for my N7 as well I let it run over night while I was sleeping.
Sent from my Nexus 7
@Nate2
I'm not sure I would be too worried about 0.1%/hr, even if the tablet never sleeps! That said, those services (Updater and PowerManager) seem more likely to be the trouble than Maps.
@Triscuit
The second image indicates Maps only held wake locks for a few minutes. Seems highly doubtful that you lost 8% of your battery charge in 5 minutes.
bftb0 said:
I conclude your OS is fine and your battery is bad in the CT702. Perhaps the full cell voltage decreases with age, but what I notice in the above is that it is saying your 98% capacity was only at 3889 mV.
Click to expand...
Click to collapse
Yes, in about 15 minutes off the charger, this CT702 loses 5% battery:
Level lost [%]: 5 Bat.: 5% (100% to 95%) [20.0%/h]
Voltage lost [mV]: 368 (4145-3777) [1472.0%/h]
A finding and a question:
1. ksmd is consuming CPU cycles. If I disable ksmd, the loadavg drops dramatically.
Code:
echo 0 > /sys/kernel/mm/ksm/run
It helps reduce battery usage.
2. I am seeing Gmail is consuming a whole lot of CPU cycles and its triggering a media scan. Is anyone else seeing this?
Code:
User 7%, System 36%, IOW 0%, IRQ 0%
User 5 + Nice 11 + Sys 76 + Idle 119 + IOW 0 + IRQ 0 + SIRQ 0 = 211
PID PR CPU% S #THR VSS RSS PCY UID Name
887 1 31% S 4 8564K 2952K fg media_rw /system/bin/sdcard
30426 0 21% S 71 1251556K 132212K bg u0_a123 com.google.android.gm
6735 0 4% R 1 2968K 1180K fg root top
Obviously, killing the process does not help because its system service and will pop right back up.
devsk said:
A finding and a question:
1. ksmd is consuming CPU cycles. If I disable ksmd, the loadavg drops dramatically.
Code:
echo 0 > /sys/kernel/mm/ksm/run
It helps reduce battery usage.
2. I am seeing Gmail is consuming a whole lot of CPU cycles and its triggering a media scan. Is anyone else seeing this?
Code:
User 7%, System 36%, IOW 0%, IRQ 0%
User 5 + Nice 11 + Sys 76 + Idle 119 + IOW 0 + IRQ 0 + SIRQ 0 = 211
PID PR CPU% S #THR VSS RSS PCY UID Name
887 1 31% S 4 8564K 2952K fg media_rw /system/bin/sdcard
30426 0 21% S 71 1251556K 132212K bg u0_a123 com.google.android.gm
6735 0 4% R 1 2968K 1180K fg root top
Obviously, killing the process does not help because its system service and will pop right back up.
Click to expand...
Click to collapse
Cool.. that's good to know. Thanks for the info! Would you say disabling that kernel process reduces battery usage a great deal?
One thing that I have noticed with CM 13/marshmallow builds in general, is that sometimes my device just *will not* connect to the mobile network; sometimes I will get lucky and it will connect just fine, but other times it cannot make a connection to save its soul. When it cannot connect, it persistently tries to connect, over and over again-- even if I'm on Wi-Fi-- and the battery is drained at a very rapid rate. However, when it does connect to the LTE network with no issues, battery drainage becomes a non-issue.
(I'm on Verizon, btw)
devsk said:
A finding and a question:
1. ksmd is consuming CPU cycles. If I disable ksmd, the loadavg drops dramatically.
Code:
echo 0 > /sys/kernel/mm/ksm/run
It helps reduce battery usage.
2. I am seeing Gmail is consuming a whole lot of CPU cycles and its triggering a media scan. Is anyone else seeing this?
Code:
User 7%, System 36%, IOW 0%, IRQ 0%
User 5 + Nice 11 + Sys 76 + Idle 119 + IOW 0 + IRQ 0 + SIRQ 0 = 211
PID PR CPU% S #THR VSS RSS PCY UID Name
887 1 31% S 4 8564K 2952K fg media_rw /system/bin/sdcard
30426 0 21% S 71 1251556K 132212K bg u0_a123 com.google.android.gm
6735 0 4% R 1 2968K 1180K fg root top
Obviously, killing the process does not help because its system service and will pop right back up.
Click to expand...
Click to collapse
I turned the KSM off in the Kernel Auditor and the loadav dropped significantly. It should be removed because it serves no purpose really and changing it every boot is a pain As for the gmail service, I just limited it's wakelocks because it was too damn frequent. But what I am wondering is, how is your loadavg 0.8? mine is 2.28 1.93 2.12 4/1437 4960 ... I think I have a major problem somwhere The lowest it has ever been is 1.60
Sinistersky said:
I turned the KSM off in the Kernel Auditor and the loadav dropped significantly. It should be removed because it serves no purpose really and changing it every boot is a pain As for the gmail service, I just limited it's wakelocks because it was too damn frequent. But what I am wondering is, how is your loadavg 0.8? mine is 2.28 1.93 2.12 4/1437 4960 ... I think I have a major problem somwhere The lowest it has ever been is 1.60
Click to expand...
Click to collapse
The loadavg depends on the apps you run. I have noticed that it spikes whenever gmail is doing the email sync or I am running videos from whatsapp etc.
So, don't worry about a larger value if you have been using the phone. The loadavg for idle phone should be close to 0, but it rarely is, because our phones are always doing something in background. The lowest I have seen it drop is 0.08, and then gmail brings it up whenever it does a sync. I have several accounts linked in gmail (yahoo, hotmail, google, work), so its understandable.
One thing you can do to monitor is to see which processes are eating up the CPU with:
Code:
ps | sort -n -k5 | tail -n 5
top -m 3 -s cpu -n 2 -d 2 | grep -v "^$" | tail -n 6
It will show 5 top memory consumers and 3 top CPU consumers. Put it in a shell script and run it periodically to collect some stats.
I have noticed dhd_dpc taking up CPU cycles. But I need the wifi... So, unless and until someone comes along and optimizes the kernel driver for wifi on M7, that's what we got! I don't think anybody would touch the driver code for m7. So, some things will never get fixed for m7.
On the other hand, the cycles eaten by system_ui and system_server are inexcusable! They can be fixed by CM/Google in non-device specific code. May be that will happen as CM13/Marshmallow matures.
devsk said:
The loadavg depends on the apps you run. I have noticed that it spikes whenever gmail is doing the email sync or I am running videos from whatsapp etc.
So, don't worry about a larger value if you have been using the phone. The loadavg for idle phone should be close to 0, but it rarely is, because our phones are always doing something in background. The lowest I have seen it drop is 0.08, and then gmail brings it up whenever it does a sync. I have several accounts linked in gmail (yahoo, hotmail, google, work), so its understandable.
One thing you can do to monitor is to see which processes are eating up the CPU with:
Code:
ps | sort -n -k5 | tail -n 5
top -m 3 -s cpu -n 2 -d 2 | grep -v "^$" | tail -n 6
It will show 5 top memory consumers and 3 top CPU consumers. Put it in a shell script and run it periodically to collect some stats.
I have noticed dhd_dpc taking up CPU cycles. But I need the wifi... So, unless and until someone comes along and optimizes the kernel driver for wifi on M7, that's what we got! I don't think anybody would touch the driver code for m7. So, some things will never get fixed for m7.
On the other hand, the cycles eaten by system_ui and system_server are inexcusable! They can be fixed by CM/Google in non-device specific code. May be that will happen as CM13/Marshmallow matures.
Click to expand...
Click to collapse
Thanks for the info. I'll try to collect some stats on my device to see what is putting a strain on the battery so much. As for the system, it has always been that way ever since lollipop came. Nobody bothers to fix it, and I am beginning to think that maybe they didn't notice the numbers or the switch from 5.0 to 6.0 happened so fast they just went "meh, we'll leave it and maybe fix it later if we remember". I never understood why most of the ROM and kernel makers try to add more new stuff without even fixing and optimizing the things that are the core of the new optimizations and add-ons. It just makes no sense to try to push something new on a broken foundation to begin with. The M7 is a great phone even now, and I had it for 3 years now. Naturally, the battery is very old now and the moment i start using the screen it drops 20% in an hour or so, making me have at most 3 hours of screen time. But with background usage restriction I get by on a daily basis just barely. Fixing the system cycles would be heavenly for me, but alas, maybe it will never happen, sadly