Related
Has anyone experienced, what I'm calling the "Dim of death"?
Basically, it only seems to happen in the browser. Things will seem ok and then the screen will go dim... basically the device freezes, but not completely. For example, I can return to the lock screen, but cannot enter my lock pattern. Pressing "play" on my bluetooth keyboard will start up a song.
The problem is, there's no recovery from the "dim of death" other than to restart the device. It's the only reason why I have to restart my transformer and the one thing that makes me affraid to use the stock browser (which I do only if I need to play flash content)
Anyone else have this problem?
Sent from my Transformer TF101 using XDA Premium App
Among all the build quality issues I have also had this too. One more reason besides light bleed dust under screen and under camera glass and bad creaking with raIr sharp ports, to send it back.
Canadoc said:
Among all the build quality issues I have also had this too. One more reason besides light bleed dust under screen and under camera glass and bad creaking with raIr sharp ports, to send it back.
Click to expand...
Click to collapse
That's a little extreme. Light bleed and dust ARE legitimate warranty issues. The rest is not really that much of a problem, unless you're looking for a reason to *****.
I have no light bleed or dust under the screen. I do have a small creaking and the occasional "dim of death". I wouldn't dream of returning this device for that.
woah! I think you guys are missunderstanding what I wrote. When the browser "crashes" the entire screen goes dim... it's a software thing and the OS becomes unresponsive. I'm not talking about dust or light bleed! LOL
Sent from my Transformer TF101 using XDA Premium App
Backlight Bug?
I have seen something similar, but not in the browser... there are times where the unit seems to lock up, but music will continue to play, and if I hit the "home" button (which isn't visible, but you can kind of guess where it is), you can VERY VAGUELY see the home screen (especially the weather lettering). You can also 'swipe' sideways from screen to screen.
I can usually duplicate this problem by adjusting the brightness, which seems to turn off the backlight (but the device is still running - you just can't see what's on the screen). Setting the brightness to "auto" seems to help a little bit.
Also, when I do a "reset", the startup display screens show properly but it will usually not startup properly - the backlight is still off. A reliable fix for me, though, is to plug the device in to charge and restart, which seems to work every time.
I'm really torn on this... this is getting very frustrating and I'm not sure whether to RMA (who knows how long that will take) or wait for a fix... (the fact that the display screens illuminate properly make me think that it's not a hardware issue...)
Do you guys have it set to auto brightness? I have it set to manual and have never seen this yet (knock on wood).
Kilmar said:
Do you guys have it set to auto brightness? I have it set to manual and have never seen this yet (knock on wood).
Click to expand...
Click to collapse
Yes, I've got mine set to auto, but I believe the dimming is more related to the OS crashing more than anything else. I just avoid the stock browser and I don't get the problem
Sent from my Transformer TF101 using XDA Premium App
EP2008 said:
Has anyone experienced, what I'm calling the "Dim of death"?
Basically, it only seems to happen in the browser. Things will seem ok and then the screen will go dim... basically the device freezes, but not completely. For example, I can return to the lock screen, but cannot enter my lock pattern. Pressing "play" on my bluetooth keyboard will start up a song.
The problem is, there's no recovery from the "dim of death" other than to restart the device. It's the only reason why I have to restart my transformer and the one thing that makes me affraid to use the stock browser (which I do only if I need to play flash content)
Anyone else have this problem?
Sent from my Transformer TF101 using XDA Premium App
Click to expand...
Click to collapse
I heard about that the newest FW-V8.2.3.13 solve this problem.
kimi_Q said:
I heard about that the newest FW-V8.2.3.13 solve this problem.
Click to expand...
Click to collapse
Nope, happened yesterday.... only in the stock browser.
Sent from my Transformer TF101 using XDA Premium App
kimi_Q said:
I heard about that the newest FW-V8.2.3.13 solve this problem.
Click to expand...
Click to collapse
I'm on FW8.2.3.13 and its happened to me as well. It happened on 8.2.3.9 as well. It only happens in two scenarios both of which involve high brightness; 1) try turning the brightness all the way up and the backlight shuts off and 2) let auto brightness turn the brightness up and it turns off.
The first three days I was on 8.2.3.13 (rooted Prime 1.3) it worked fine to where I could adjust brightness to any level. I installed some games and a task manager after that so I guess ill start by removing the task manager.
Its happened in Google books and the browser for me.
Sent from my Transformer TF101 using Tapatalk
This has happened to me once before, but I can't remember if it was before or after the update. The browser went dim and was unresponsive, but then I think it either gave me the option to force close or I let it sit for a minute and hit back and managed to get to the home screen and then force closed the browser through the application settings page.
I just bought the 32GB model (and keyboard dock) and this happens right from the box. During the initial setup it wants to create a Google account. As soon as the browser inits the screen goes black. Holding the power button for 10 seconds causes a reset and it reboots to the same point. I had to create the account on my PC and then was able to go past. Then the OTA tried to spawn the browser and tanked. Grrr! I just did a factory reset; hopefully the restore ROM they have is clean otherwise I'm going to frisbee this bloody unit across the room!
Worth mentioning? The screen blacks out when running Android Market as well, but _not_ the YouTube app. Is it just segfaulting on a shared lib?
Firefox, DolphinHD, and Angry Birds all cause the screen to go black. In the case of Angry Birds, the music continues to play so the machine isn't frozen; it has merely turned off the display. logcat seems to bear this out as you can see it setting display brightness to 0. Why, I cannot say.
haven't had this yet.
seshmaru said:
haven't had this yet.
Click to expand...
Click to collapse
Your post is entirely unhelpful.
Anyways...I uninstalled "taskpanel" but now i'm too afraid to turn up the brightness because i'm not sure if it will go dim or not.
The backlight turns off even when i'm on the homescreen and set the brightness to max.
I installed Firefox and it will make the screen black out as well. Dmesg shows Tegra_pwm going into pwm and setting the display to 0 but it doesn't show the caller! I either have to press the power key multiple quick presses in a row or hold for 10 seconds. Gratingly, the "Power Off" dialog will illuminate the screen but immediately blackout again when I click Cancel. ACV, terminal basically any app that doesn't use a library common to browsers and Android Marker (Gmail app as well.) As above, the YouTube app functions perfectly, so I know both the unit and the networking stack is functional to a point. I am curious as to how these units paint the screen; is it a WM on X or a binary-blob to the framebuffer?
A factory reset did nothing, sadly. Given that I cannot scan the filesystem (I'm thinking a corrupt node exists) I need a way to wipe the internal flash and put a fresh image down (after scanning the MTD.) Any ideas?
Cheers,
Todd.
(PS: I've been lurking for a while so I'll pre-answer some common questions. I've minor light bleed from lower left at extreme angles, no obvious creaking, sound appears balanced and I've yet to get zapped by the charger. Without the web its difficult to install test apps! )
Weird. I have the screen timeout set to "never" and the brightness manually set to 60% and it still turns off the screen, even when idle at the homescreen. I have it docked; does this alter how it does power management?
Finally got logcat going
I tapped the browser icon and the screen blacks out as expected. The following entries are written to the log:
Code:
05-20 10:43:37.220: INFO/ActivityManager(127): Starting: Intent { act=android.intent.action.MAIN cat=[android.intent.category.LAUNCHER] flg=0x10200000 cmp=com.android.browser/.BrowserActivity bnds=[144,645][240,741] } from pid 223
05-20 10:43:37.250: DEBUG/SurfaceFlinger(127): screenshot: sw=230, sh=143, minZ=0, maxZ=21005
05-20 10:43:37.280: DEBUG/SurfaceFlinger(127): screenshot: result = OK
05-20 10:43:37.330: DEBUG/dalvikvm(127): GC_CONCURRENT freed 595K, 7% free 9490K/10183K, paused 3ms+4ms
05-20 10:43:37.350: INFO/ActivityManager(127): Start proc com.android.browser for activity com.android.browser/.BrowserActivity: pid=786 uid=10054 gids={3003, 1015}
05-20 10:43:37.390: DEBUG/WindowManager(127): readLidState, sw:1
05-20 10:43:37.390: DEBUG/WindowManager(127): adjustConfigurationLw, config:{ scale=1.0 imsi=0/0 loc=null touch=3 keys=2/1/1 nav=1/1 orien=L layout=0x10000014 uiMode=0x0} mLidOpen:1 config.hardKeyboardHidden:1
05-20 10:43:37.410: DEBUG/dalvikvm(86): GC_EXPLICIT freed 12K, 6% free 6202K/6531K, paused 8ms+1ms
05-20 10:43:37.440: INFO/ActivityThread(786): Pub com.android.browser;browser: com.android.browser.provider.BrowserProvider2
05-20 10:43:37.450: DEBUG/dalvikvm(86): GC_EXPLICIT freed <1K, 6% free 6202K/6531K, paused 1ms+1ms
05-20 10:43:37.450: INFO/ActivityThread(786): Pub com.android.browser.home: com.android.browser.homepages.HomeProvider
05-20 10:43:37.490: DEBUG/dalvikvm(86): GC_EXPLICIT freed <1K, 6% free 6202K/6531K, paused 1ms+2ms
05-20 10:43:37.520: INFO/BrowserSettings(786): Selected search engine: ActivitySearchEngine{[email protected]}
05-20 10:43:37.600: DEBUG/dalvikvm(786): GC_CONCURRENT freed 135K, 4% free 6563K/6791K, paused 3ms+2ms
05-20 10:43:37.980: DEBUG/dalvikvm(786): GC_CONCURRENT freed 51K, 3% free 7015K/7175K, paused 2ms+1ms
05-20 10:43:37.990: DEBUG/dalvikvm(786): GC_FOR_ALLOC freed 1K, 3% free 7014K/7175K, paused 14ms
05-20 10:43:38.000: INFO/dalvikvm-heap(786): Grow heap (frag case) to 7.420MB for 513744-byte allocation
05-20 10:43:38.010: DEBUG/dalvikvm(786): GC_FOR_ALLOC freed <1K, 3% free 7515K/7687K, paused 16ms
05-20 10:43:38.030: DEBUG/dalvikvm(786): GC_CONCURRENT freed 4K, 2% free 7540K/7687K, paused 1ms+1ms
05-20 10:43:38.040: INFO/SqliteDatabaseCpp(786): sqlite returned: error code = 1, msg = index cookie_times already exists, db=/data/data/com.android.browser/databases/webview.db
05-20 10:43:38.070: INFO/SqliteDatabaseCpp(786): sqlite returned: error code = 1, msg = index cookie_times already exists, db=/data/data/com.android.browser/databases/webview.db
05-20 10:43:38.100: DEBUG/dalvikvm(786): GC_FOR_ALLOC freed 505K, 9% free 7039K/7687K, paused 15ms
05-20 10:43:38.140: DEBUG/dalvikvm(786): GC_CONCURRENT freed 2K, 2% free 7548K/7687K, paused 2ms+1ms
05-20 10:43:38.220: INFO/ActivityManager(127): Start proc com.google.android.gsf.login for service com.google.android.gsf.login/com.google.android.gsf.loginservice.GoogleLoginService: pid=805 uid=10022 gids={3003, 1015, 2001, 1007}
05-20 10:43:38.260: WARN/TestFlashPlugin(786): support: true
05-20 10:43:38.260: VERBOSE/TLINE(786): new: [email protected]
05-20 10:43:38.290: INFO/ActivityManager(127): No longer want com.google.android.gm (pid 561): hidden #16
05-20 10:43:38.300: DEBUG/libEGL(786): loaded /system/lib/egl/libGLES_android.so
05-20 10:43:38.310: DEBUG/libEGL(786): loaded /system/lib/egl/libEGL_tegra.so
05-20 10:43:38.320: DEBUG/libEGL(786): loaded /system/lib/egl/libGLESv1_CM_tegra.so
05-20 10:43:38.320: DEBUG/libEGL(786): loaded /system/lib/egl/libGLESv2_tegra.so
05-20 10:43:38.340: DEBUG/OpenGLRenderer(786): Creating OpenGL renderer caches
05-20 10:43:38.340: DEBUG/OpenGLRenderer(786): Enabling debug mode 0
05-20 10:43:38.340: DEBUG/OpenGLRenderer(786): Layers will be composited as regions
05-20 10:43:38.430: INFO/ActivityManager(127): Displayed com.android.browser/.BrowserActivity: +1s91ms
05-20 10:43:38.450: DEBUG/PhoneWindow(223): couldn't save which view has focus because the focused view [email protected] has no id.
05-20 10:43:41.850: DEBUG/dalvikvm(786): GC_CONCURRENT freed 299K, 5% free 7733K/8135K, paused 2ms+2ms
05-20 10:43:43.500: DEBUG/dalvikvm(223): GC_EXPLICIT freed 162K, 18% free 15729K/19143K, paused 3ms+3ms
05-20 10:43:46.120: WARN/webcore(786): Can't get the viewWidth after the first layout
05-20 10:43:46.130: DEBUG/BrowserLogin(786): Finished login attempt for [email protected]
05-20 10:43:46.180: DEBUG/webviewglue(786): nativeDestroy view: 0x272e60
05-20 10:43:46.210: DEBUG/dalvikvm(786): GC_FOR_ALLOC freed 281K, 6% free 7786K/8199K, paused 16ms
05-20 10:43:46.230: DEBUG/dalvikvm(786): GC_FOR_ALLOC freed 25K, 6% free 7981K/8455K, paused 16ms
05-20 10:43:47.200: INFO/TextType(210): TextType = 0x0
05-20 10:44:02.270: ERROR/Tab(786): onReceivedError -6 The connection to the server was unsuccessful.
05-20 10:44:02.340: DEBUG/dalvikvm(786): GC_CONCURRENT freed 198K, 5% free 8316K/8711K, paused 2ms+2ms
When I attempt a screen shot (through Eclipse) I get a "Screen Unavailable" message and then this in logcat:
Code:
05-20 10:45:00.000: INFO/dalvikvm(127): Jit: resizing JitTable from 4096 to 8192
05-20 10:45:04.890: DEBUG/dalvikvm(786): GC_CONCURRENT freed 678K, 10% free 8270K/9095K, paused 3ms+2ms
05-20 10:45:12.710: DEBUG/SntpClient(127): request time failed: java.net.SocketTimeoutException: Try again
05-20 10:46:07.920: DEBUG/SntpClient(127): request time failed: java.net.SocketTimeoutException: Try again
05-20 10:46:14.160: DEBUG/SurfaceFlinger(127): screenshot: sw=1280, sh=800, minZ=0, maxZ=-1
05-20 10:46:14.310: DEBUG/SurfaceFlinger(127): screenshot: result = OK
05-20 10:46:19.350: INFO/DEBUG(85): debuggerd committing suicide to free the zombie!
05-20 10:46:19.360: INFO/DEBUG(853): debuggerd: May 11 2011 22:26:41
05-20 10:46:27.930: DEBUG/SntpClient(127): request time failed: java.net.SocketTimeoutException: Try again
05-20 10:46:30.050: DEBUG/BatteryService(127): level:96 scale:100 status:5 health:2 present:true dock_status:4 dock_level:68 voltage: 8 temperature: 270 technology: Li-ion AC powered:true USB powered:false icon:17302692 invalid charger:0
05-20 10:46:30.060: DEBUG/WifiService(127): ACTION_BATTERY_CHANGED pluggedType: 1
05-20 10:46:30.060: DEBUG/UiModeManager(127): Display mobile dock notificaiton, level:68 status:4
05-20 10:46:30.070: INFO/fdhttpd(646): battery level:96 plugged:1
05-20 10:46:30.070: DEBUG/PowerUI(190): closing low battery warning: level=96
Any takers?
When clicking the power button twice, the screen flickers (on press #2) but remains off. The following is emitted:
Code:
05-20 10:52:20.800: DEBUG/PowerManagerService(127): @PowerManagement: Sleep state requested, reason:2
05-20 10:52:20.800: DEBUG/PowerManagerService(127): @PowerManagement: Screen Bright {true -> false}
05-20 10:52:21.100: INFO/power(127): *** set_screen_state 0
05-20 10:52:21.100: DEBUG/SurfaceFlinger(127): screenshot: sw=230, sh=143, minZ=0, maxZ=21010
05-20 10:52:21.100: DEBUG/PowerManagerService(127): @PowerManagement: Screen turned off mScreenOnTime=1700988ms Battery<C,V>: <96,8>
05-20 10:52:21.100: DEBUG/PowerManagerService(127): @PowerManagement: Acquire UWL 'sleep_broadcast' flags [partial] refcount=1
05-20 10:52:21.110: DEBUG/SurfaceFlinger(127): About to give-up screen, flinger = 0x135fc8
05-20 10:52:21.120: DEBUG/SurfaceFlinger(127): screenshot: result = OK
05-20 10:52:21.130: DEBUG/PowerManagerService(127): @PowerManagement: sending ordered bcast for ACTION_SCREEN_OFF
05-20 10:52:21.130: DEBUG/WifiService(127): ACTION_SCREEN_OFF
05-20 10:52:21.140: DEBUG/AlarmManager(127): Added alarm Alarm{4098c8e8 type 2 com.google.android.gsf} type:ELAPSED_REALTIME_WAKEUP when: After 0h:4m:59.0s
05-20 10:52:21.150: DEBUG/PowerManagerService(127): @PowerManagement: Release UWL 'sleep_broadcast' flags [partial] refcount=0
05-20 10:52:26.190: DEBUG/dalvikvm(223): GC_EXPLICIT freed 77K, 19% free 15652K/19143K, paused 4ms+2ms
05-20 10:52:46.030: INFO/power(127): *** set_screen_state 1
05-20 10:52:46.030: DEBUG/PowerManagerService(127): @PowerManagement: Screen Bright {false -> true}
05-20 10:52:46.030: DEBUG/PowerManagerService(127): @PowerManagement: Screen turned on mScreenOffTime=24929ms Battery<C,V>: <96,8>
05-20 10:52:46.030: DEBUG/PowerManagerService(127): @PowerManagement: Acquire UWL 'sleep_broadcast' flags [partial] refcount=1
05-20 10:52:46.040: DEBUG/WindowManager(127): readLidState, sw:1
05-20 10:52:46.140: DEBUG/WindowManager(127): adjustConfigurationLw, config:{ scale=1.0 imsi=0/0 loc=null touch=3 keys=2/1/1 nav=1/1 orien=L layout=0x10000014 uiMode=0x0} mLidOpen:1 config.hardKeyboardHidden:1
05-20 10:52:46.180: DEBUG/PowerManagerService(127): @PowerManagement: sending ordered bcast for ACTION_SCREEN_ON
05-20 10:52:46.180: DEBUG/WifiService(127): ACTION_SCREEN_ON
05-20 10:52:46.190: WARN/TestFlashPlugin(786): support: true
05-20 10:52:46.220: DEBUG/PowerManagerService(127): @PowerManagement: Release UWL 'sleep_broadcast' flags [partial] refcount=0
05-20 10:52:46.470: DEBUG/SurfaceFlinger(127): Screen about to return, flinger = 0x135fc8
I wish I understood what that stuff means Todd. I should note that for me, this problem only happens in the browser. I have Flash "always on" and it seems to only happen when I'm viewing flash content. I do have auto brightness on with a 5 minute timeout on my device.
Sent from my Transformer TF101 using XDA Premium App
I'm right now on LiGuxV4.1 and was having trouble with battery life, the users mentioned to reduce the screen brightness but that did not help much. So, I started looking at logcat and I'd like to know if the following could be of any concern,
At every regular interval (2 Mins), I see,
D/AK8975 ( 116): Compass Start
D/AK8975 ( 116): Compass CLOSE
Is that for Location or Google Now or anything that could be eating battery ?
Also, when I try to access audio files, I see,
W/WVMExtractor( 112): Failed to open libwvm.so
D/Ringtone(13775): Successfully created local player
Should this be corrected?
Please help me with these as well as anything that can help me with better battery life.
Since its a ported ROM there must be a file/sensor running that's draining the battery.
Sent from my HTC One S using Tapatalk 2
So I boot up that N7 and everything works great. Until I press the power button once to lock it and then again to unlock it. After that, the touchscreen does not respond to anything. The rest is good - ADB works and it shows that it's charging when I connect it to the PC or the charger.
What could be the possible issue?
I tried reflashing the tab, problem persists on both 4.1.2 and 4.2.2 stock ROMs.
Spaqin said:
So I boot up that N7 and everything works great. Until I press the power button once to lock it and then again to unlock it. After that, the touchscreen does not respond to anything. The rest is good - ADB works and it shows that it's charging when I connect it to the PC or the charger.
What could be the possible issue?
I tried reflashing the tab, problem persists on both 4.1.2 and 4.2.2 stock ROMs.
Click to expand...
Click to collapse
Very wierd issue that almost seems hardware related. You have tried a factory reset correct?
I would guess that flashing the stock ROM through fastboot is more or less a factory reset. I will try to do that from Android too.
I'm pretty sure this is software related bug - TWRP doesn't have any problems with waking up.
Problem persists even on a custom kernel - LeanKernel. I will try to flash a custom ROM soon if that factory reset won't help.
[edit]
So I used logcat and it gave me this:
Code:
I/PowerManagerService( 481): Going to sleep by user request...
D/SurfaceFlinger( 128): Screen released, type=0 flinger=0x405ca318
I/WindowManager( 481): No lock screen!
D/dalvikvm( 481): GC_CONCURRENT freed 946K, 21% free 11856K/14860K, paused 4ms+5ms, total 62ms
D/dalvikvm( 481): WAIT_FOR_CONCURRENT_GC blocked 24ms
D/dalvikvm( 481): WAIT_FOR_CONCURRENT_GC blocked 34ms
D/NfcService( 843): NFC-C OFF, disconnect
D/dalvikvm( 481): GC_CONCURRENT freed 468K, 16% free 12484K/14860K, paused 3ms+3ms, total 47ms
D/dalvikvm( 481): WAIT_FOR_CONCURRENT_GC blocked 44ms
D/dalvikvm( 481): GC_FOR_ALLOC freed 139K, 17% free 12475K/14860K, paused 72ms, total 72ms
D/dalvikvm( 481): GC_FOR_ALLOC freed 132K, 17% free 12452K/14860K, paused 72ms, total 72ms
D/dalvikvm( 481): GC_FOR_ALLOC freed 104K, 15% free 12635K/14860K, paused 71ms, total 72ms
D/PhoneStatusBar( 731): disable: < expand icons alerts ticker system_info back home RECENT* clock search >
V/TAG ( 481): bug 7643792: fitSystemWindows([0,33][0,0])
V/TAG ( 481): bug 7643792: fitSystemWindows([0,33][0,0])
D/libEGL ( 481): loaded /system/lib/egl/libEGL_tegra.so
D/dalvikvm( 1983): GC_CONCURRENT freed 262K, 5% free 7433K/7820K, paused 1ms+2ms, total 23ms
D/libEGL ( 481): loaded /system/lib/egl/libGLESv1_CM_tegra.so
D/libEGL ( 481): loaded /system/lib/egl/libGLESv2_tegra.so
D/OpenGLRenderer( 481): Enabling debug mode 0
D/PhoneStatusBar( 731): disable: < expand icons alerts ticker system_info BACK* HOME* RECENT clock search >
I/PowerManagerService( 481): Waking up from sleep...
I/WindowManager( 481): Lock screen displayed!
D/PowerManagerService-JNI( 481): Excessive delay in autosuspend_disable() while turning screen on: 262ms
D/SurfaceFlinger( 128): Screen acquired, type=0 flinger=0x405ca318
(turned logcat a bit earlier [lots of different stuff there, just ignored it], used the power button to get the device to sleep, pressed it again to unlock, touchscreen does not respond, ctrl+c'd from logcat.)
Spaqin said:
I would guess that flashing the stock ROM through fastboot is more or less a factory reset. I will try to do that from Android too.
I'm pretty sure this is software related bug - TWRP doesn't have any problems with waking up.
Problem persists even on a custom kernel - LeanKernel. I will try to flash a custom ROM soon if that factory reset won't help.
Click to expand...
Click to collapse
So the touchscreen does respond in TWRP? Im not sure what to suggest. Thats very wierd. I hope a solution arises. Good luck
Yeah. Neither a new kernel (tried franco's too), nor CM10.1 seem to solve the issue. It still works good after the boot for practically infinite amount of time and it works great.
I just got the tab to fix that issue, and talked to my friend who has a N7 too (but fully working of course) - he said he had a similar issue with his magnetic cover. I guess that the magnetic sensor could be damaged in some way. It's not my N7, I'm not going to open it to check.
Spaqin said:
Yeah. Neither a new kernel (tried franco's too), nor CM10.1 seem to solve the issue. It still works good after the boot for practically infinite amount of time and it works great.
I just got the tab to fix that issue, and talked to my friend who has a N7 too (but fully working of course) - he said he had a similar issue with his magnetic cover. I guess that the magnetic sensor could be damaged in some way. It's not my N7, I'm not going to open it to check.
Click to expand...
Click to collapse
This thread has a solution to disable the magnetic sensor and this link talks about google currents as a possible culprit (even though the issue doesn't exactly match yours, it may be worth a try).
Yeah.
Shame that nobody introduced that thing into their kernel :X and CM10.1 is google app-less unless I install them.
Thanks for your advice though! I will give the tab back to the owner, maybe he will want to disassemble it and try to fix the issue.
Spaqin said:
Yeah.
Shame that nobody introduced that thing into their kernel :X and CM10.1 is google app-less unless I install them.
Thanks for your advice though! I will give the tab back to the owner, maybe he will want to disassemble it and try to fix the issue.
Click to expand...
Click to collapse
No problem at all :good:
Some time ago my phone started playing up - I would feel it vibrate in my pocket and would pull it out to check the notification... It was being shut down.
A few weeks went by an this would happen occasionally, then one day after a random shutdown the phone would shut down immediately after booting into the system. Well things has gotten worse, and now these shut down events are frequent and for the last few days my phone has been useless. Like this: http://www.youtube.com/watch?v=LzNO_VVC3zg
When this all started I was on a mainstream custom 4.2.2, and having thought maybe this would be fixed in another ROM I have tried another mainstream custom 4.2.2, 4.3, and Stock 4.2.2 and 4.3 (relocked,fully wiped). Alas my issues were not going away so I had to try fix this, so I tried another battery - no good.
No matter the random shut downs, I had a stable recovery/fastboot to reflash, and the phone was charging when powered off.
So during one of these small periods of time when my phone was stable I set up ADB and started up Logcat Reader. After two crashes and again trying both batteries I had some logs...
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 7 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 6 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 5 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 4 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 3 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 2 at 79.0 degC
D/ThermalDaemon(182): Sensor 'batt_therm' - alarm raised 1 at 79.0 degC
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[0] to 1188000
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[1] to 1188000
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[2] to 1188000
D/ThermalDaemon(182): ACTION: CPU - Setting CPU[3] to 1188000
D/ThermalDaemon(182): ACTION: LCD - Setting max LCD brightness to 181
D/ThermalDaemon(182): ACTION: BATTERY - Setting battery charging mitigation to 3
I/ActivityManager(515): START u0 {act=android.intent.action.ACTION_REQUEST_SHUTDOWN flg=0x10000000 cmp=android/com.android.server.ShutdownActivity (has extras)} from pid 515
This being my first look at these things, I look through each of the logs and see what looks like normal battery temperatures (hovering between 30 and 40 degC), but at some seemingly random time we have a 79.0 degC battery and subsequent shutdown.
I have extracted out of \system\etc\ on a few of these ROMs and ThermalDaemon appears to be doing as expected.
[batt_therm]
sampling 5000
thresholds 360 370 380 390 410 420 450
thresholds_clr 350 360 370 380 400 410 440
actions cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery cpu+gpu+lcd+battery
action_info 1512000+400000000+240+0 1296000+325000000+215+0 1296000+325000000+192+0 1188000+200000000+181+1 1188000+200000000+181+1 1188000+200000000+181+2 1188000+200000000+181+3
At 79.0 degC the values should be set to 1188000,200000000,181 and 3.
So - why 79.0degC if the battery is not hot (faulty batteries? faulty power management IC? some other bug?), and what is the affect of 'setting battery charging mitigation to 3' and what calls the ACTION_REQUEST_SHUTDOWN?
Obviously I have no chance to RMA, but would be happy to resurrect this phone some how.
Could be a software issue within the kernel or worse in a folder such has /dev/ or /persist/.
It looks like a countdown was triggered.
The thermal needs a calibration for sure.
Sent from my Nexus 4 using Tapatalk 4
Well I have tried 2.0, 2.2.2, 2.3 stock, CM, AOKP, trinity, faux kernel and a few others so this very much feels like a hardware problem however the way in which software interacts with hardware could also be at fault. All give the same result - the phone (usually) boots first time and stays online for a while then shuts down. Once the first shutdown occurs, the phone will typically shut down right after booting until a wipe/install is done.
With faux kernel options disabling the default thermal management things seemed a little better for a while but then it shut down again. I have tried logging this, and at least in the first instance it didn't look like the batt_therm was hitting 79.0 degC on this kernel but I haven't identified the cause in software/hardware at this point.
I'm getting this too, but at a lower temperature
D/ThermalDaemon( 204): Sensor 'batt_therm' - alarm raised 7 at 45.9 degC
D/ThermalDaemon( 204): ACTION: BATTERY - Setting battery charging mitigation to 3
Followed by a shutdown.
I/ActivityManager( 723): START u0 {act=android.intent.action.ACTION_REQUEST_SHUTDOWN flg=0x10000000 cmp=android/com.android.server.ShutdownActivity (has extras)} from pid 723
I can make the error more likely by running some programs. E.G. rymdkapsel is very effective at shutting down my phone after a couple of minutes playing.
I'm going to dig into that ThermalDaemon code to see what is happening. It may be worth compiling a new one a cutting out the sensor alarm behavior to see if that stop it, to show whether or not it is that code that is in the failure path.
David_Johnston said:
I'm going to dig into that ThermalDaemon code to see what is happening. It may be worth compiling a new one a cutting out the sensor alarm behavior to see if that stop it, to show whether or not it is that code that is in the failure path.
Click to expand...
Click to collapse
I think I chucked the system board for this phone after buying a replacement (broken screen) nexus 4. Good luck with your testing and do report back.
Maybe I can block it here..
muzzl3 said:
I think I chucked the system board for this phone after buying a replacement (broken screen) nexus 4. Good luck with your testing and do report back.
Click to expand...
Click to collapse
I changed all the shutdown actions in the thermald config to 'none' to no effect. It still shuts down randomly.
I changed the battery to a new one to no effect.
So I got myself the cyanogenmod sources and started searching for things that might be issuing the request.
frameworks/base/services/java/com/android/server/BatteryService.java looks like the culprit. It has two methods shutdownIfNoPowerLocked() and shutdownIfOverTempLocked() that issue the request. Also it waits until the system has booted before it issues the request, which fits with the pattern of it fully booting before shutting down on the times that it shuts down right after powering it on.
I'm rebuilding form source, which is taking all day. Once that is done, I'm going to set the user confirmation flag in the action request to see if this is the code in the failure path. If so, that doesn't explain the cause, but it provides a way to block the effect and then trace back to the cause.
Success..
It's the shutdownIfOverTempLocked() routine that is firing and shutting down the phone.
I changed the call to require a user acknowledge so it would not actually shut the phone down and I added a log to see which one was causing it..
[email protected]:~$ grep shutdownIf logcat.txt
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
I/BatteryService( 723): shutdownIfOverTempLocked() Firing
So the temporary fix is to change 'false' to 'true' in line 339 of BatteryService.java and recompile android, or just BatteryService.java if you know how to do that in isolation.
I presume it's a sensor problem. I'm going to dig in and see what is causing it to fire on this condition and see if there isn't a software mitigation that can be put in place.
Am I the only one who would not try to mess with a phone that raises a battery temperature alert?
Especially with lithium batteries I would not touch that thing again.
Well. Trust me, I'm an engineer . Actually I'm an engineer who spent part of my like designing LiIon and LiPoly charging circuits for cell phones and I'm not at all concerned.
1) The thermal sensor is returning bogus values. If the values are bogus, the thermal overload clearly isn't working with or without the patch. So if there was a problem, thousands of affected users would be at risk.
2) The battery isn't hot. It's cold.
3) You can't make these things burn. I've tried. The ones that burn have faulty manufacturing.
4) A burn scenario is a runaway reaction, there's nothing the software can do about it one way or the other.
5) I don't believe it's the thermal sensor. Thermal sensors don't just break like that, especially uniformly across so many devices. I've changed the battery and it carried on - the sensor is in the battery. The problem is in the phone, not the sensor.
---------- Post added at 06:28 PM ---------- Previous post was at 05:57 PM ----------
thermald looks at a number of temperature sensors, including the battery sensor and the configuration file tells it to shut down on several of the sensors when they hit a max. However thermald does not issue shutdowns for the battery thermal sensor limit. It implements the clock throttling at different temperature points, the idea being that the battery will never get to the max temp.
So when the thermal sensor erroneously reports a max temp, thermald raises all sorts of alarms that you see in the logs and slows your clocks, but it does not shut off the phone.
The code that shuts off the phone is in BatteryService.java and BatteryService.java gives you no logs whatsoever when in does what it does. The logs above are what I added and it happens once for each time the phone erroneously tries to shut down.
So it's easy to see the alarms in the log, see the shutdown happen and conclude that thermald is doing it, but it isn't. BatteryService.java is doing it and is being stealthy while it does it.
I would link to my android image with the mitigation but this web site isn't letting me include urls.
I experienced the same problem on a Nexus 4.
I replaced the screen myself, the phone updated to 4.3 shortly after and the problem started to occur. I rooted the device and installed CatLog, and I get the same sequence of messages: batt_therm reports 79.0°C, raises all the alarms, and then the shutdown command is issued - but the device isn't hot at all. It also happens just after the device boots. This behavior seems unpredictable, and isn't related to real temperature - making the device hot doesn't make the problem more or less likely to occur. I bought a new battery from an LG vendor and replaced it, but the problem is still here, so it doesn't seem to be a component failure.
Did you made any progress during your investigations?
eva03_sp said:
I experienced the same problem on a Nexus 4.
Did you made any progress during your investigations?
Click to expand...
Click to collapse
I too had this issue. Stopped using my nexus 4 for more than an year due this random shutdown issue.
A few months back I was recording logcat and found that battery temp is reported as 79C and eventually that is triggering a shutdown. But the battery and device is chill cold. Tried several custom roms and kernels and changed the thermald thresholds etc etc. But nothing helped. Could not find any fix to suppress this. and kept the device back in the shelf. When I wanted to get rid of nexus 4 to get a new one.. I thought of giving a final attempt to fix the issue. Found this thread.
Here is how I fixed it.
1) Installed latest cyanogenmod rom (stock rom is also fine.. but need to deodex and odex back)
2) extracted the services.jar from /system/framework folder to my PC.
3) downloaded the smali.jar and baksmali.jar from this post (//forum.xda-developers.com/galaxy-s2/themes-apps/how-to-manually-deodex-odex-t1208320)
4) extract the classes.dex file from the services.jar
5) java -jar baksmali.jar classes.dex (seep the dex file in same folder as the baksmali.jar)
6) this generates an out folder. with the smali files. Look for BatteryService$3.smali file
Look for..
__60 .line 298
__61 new-instance v0, Landroid/content/Intent;
__62
__63 const-string v1, "android.intent.action.ACTION_REQUEST_SHUTDOWN "
__64
__65 invoke-direct {v0, v1}, Landroid/content/Intent;-><init>(Ljava/lang/String V
__66
__67 .line 299
__68 .local v0, "intent":Landroid/content/Intent;
__69 const-string v1, "android.intent.extra.KEY_CONFIRM"
__70
__71 const/4 v2, 0x0
FIX A)
At Line 71 -> replace 0x0 with 0x1
This change when implemented, will make a dialog poup before shutdown. You can click on cancel to avoid the shutdown.
FIX B)
But if you don't want that annoying dialog, and just want to avid the shutdown silently.
At Line 63 -> replace ACTION_REQUEST_SHUTDOWN with ACTION_BATTERY_OKAY
You dont need to modify line 71. You have to keep it 0x0
6) Once the smali file is modified compile the dex file back using the below command
java -jar smali.jar out -o classes.dex
Make sure the out folder has all the files including the modified it their exact locations
7) Now use winrar to open the services.jar and drag drop the new classes.dex file into it.
WINRAR will ask if you would like to replace the classes.dex file. Choose YES. Also in the compression mechanism choose store.
8) Now copy the services.jar file back to the phone. First keep it in /system. NOT /system/framework. and using a root file manager first set uid and gid to 0 (root) and set the permissions rw-r-r
9) NOW move to /system/framework folder.
10 That's it. Reboot the phone and enjoy the fix.
I tried out FIX A. I am seeing it action.. Simply cancelling the dialogs for now. If I can't bear that annoyance any more I'll try the FIX B.
Hope this helps.
Hi,
You saved my life. really I had the similar issue with my Samsung TAB PRO. shutdown when sleep.
I was lost for month until i found your Post here in XDA and followed your instructions and resolved the issue!!
My process must have changed - slightly.
https://forum.xda-developers.com/galaxy-tab-pro-12-10-8/development/rom-7-1-xsm-t900-unofficial-cyanogenmod-t3524853/post78826518
So many thanks for detailed professional explaining and description.
Robert
I just recently installed Lineage OS v16 on my N910V using lineage-16.0-20190912-UNOFFICIAL-trlte. I also installed the nano version of GApps. I did a 100% complete & clean install of the firmware. Wiped all the partitions, dalvik cache, even my data, and even formatted just as the instructions asked.
Every thing seemed to work great until I noticed the GPS was not working or maybe only partially working, I'm not sure. I installed GPS Test to test my GPS. The app is highly confusing but it does show much activity. The 'In View' value always fluctuates between about 15-20. The 'In Use' value always displays 0. The visual bar graphs below theses values are almost always fluctuating up and down and changing their positions. The 'GNSS Status' box always says "No Fix". The 'Accuracy' value fluctuates usually between 9-13 ft.
So I figured if the bar graphs are present and moving consistently, shouldn't that mean my GPS element is at least detected? I'm not sure if it's working correctly, since it keeps saying No Fix, but the GPS element itself must be present for it to even show any results, correct?
I ask this because I installed MapQuest and it said "No GPS available: Since this device doesn't have a GPS element, we'll do the best we can to find your location using Wi-Fi. However, somethings like turn-by-turn will not be available. " Google Maps had the same issue, though it doesn't inform you like MapQuest does. The only reason I know the GPS isn't working properly in Google Maps is because it wouldn't give me turn-by-turn directions.
Any suggestions? I have root, so is there anything I need to check or modify?
I've uploaded a logfile from LogCat. I turned on Location immediately after starting LogCat, so hopefully it helps in troubleshooting.
I 'd appreciate any feedback or suggestions.
I noticed a few errors relating to GPS right off:
09-15 19:04:11.698 756:770 E/LocSvc_eng]
E/int loc_eng_init(loc_eng_data_s_type&, LocCallbacks*, LOC_API_ADAPTER_EVENT_MASK_T, loc_core::ContextBase*): log_eng state error: instance already initialized
[09-15 19:04:11.698 756:770 E/]
E/open failed: /dev/mdm: No such file or directory
[09-15 19:04:11.698 756:770 E/LocSvc_eng]
E/void loc_eng_agps_init(loc_eng_data_s_type&, AGpsExtCallbacks*): log_eng state error: agps instance already initialized
[09-15 19:04:11.718 1340:2195 E/inertial-anchor]
Called Stop() before session has started.
[09-15 19:04:11.784 756:1154 E/LocSvc_EngAdapter]
E/void LocEngAdapter::setXtraUserAgent()::LocSetXtraUserAgent::saveUserAgentString(const char*, int) const:149]: make XTRA_FOLDER failed
Strange: Good GPS function but no "lock" reported
I have the same issue with my Note 4 910T. I never see lock on GPS Test or any other app. But: I tested the gps in airplane mode along with another Note4 (Stock 6) I have (which shows lock and about 20 satellites), and they give identical tracks (distances identical to 0.01 mile) even up narrow canyons. So I think it's a problem of the GPS reports somehow not the function.