set RootExplorer
find the file /system/build.prop
They change the option
ro.mot.phonemode.vzwglobalphone=1
on
ro.mot.phonemode.vzwglobalphone=0
The signal quality jumped several times, the signal is no longer walks to and fro, all thanks.
Original: http://www.droidforums.net/forum/dr...acking-tweaking-3g-settings-radio-driver.html
The 3G tweak is as follows:
Open root explorer (or whices) and navigate to /data, long click local.prop and scroll down to open in text editor. at the end of local.prop add the following lines and an extra empty line at the end, then reboot. voila you should have a more consistent, less laggy 3G connection.
You can find a scripted 3G tweak in zeppelin's newst verion of supercharger. Be warned though as this may not work at all or it may softbrick all wireless connections
the code is (much thanks goes out to Zeppelinrox)
ro.ril.hsxpa=3
ro.ril.gprsclass=12
ro.ril.hep=1
ro.ril.enable.dtm=1
ro.ril.hsdpa.category=28
ro.ril.enable.a53=1
ro.ril.enable.3g.prefix=1
ro.ril.htcmaskw1.bitmask=4294967295
ro.ril.htcmaskw1=14449
ro.ril.hsupa.category=9
again, save this at the end of build.prop WITH an extra empty line at the end, reboot and you're done. you may notice overall smoother download speeds, higher upload, and faster ping-pong roundtrips.
Now for the fun part! you can try this at your own risk, I have had no problems in the execution of this hack. Much thanks goes out to monks700 for helping me figure things out.
The Radiocomm radio driver Throttle Remover hack!
Okay so this should be relatively straightforward.
Radiocomm will run on W7 32-bit (also 64 bit. ignore any warnings/errors).
You need version 11.11.7 (download link is at the bottom of this post)
. The MA should be set to common->MDM 6x00,
Under the menu Settings->USB you should select PST driver.
Plug in the phone and put it in PC mode.
Radio detection should turn from red to green, A few motorola drivers may install.
Then use the arrow buttons at the middle right of the screen to scroll to the P2K 4 tab.
In the STElem / RDELEM box you will see a few text fields:
change element id to 01C2
record to 0001
offset is unchanged and
length to 0001
Data is 01
Press STELEM (one of the buttons in the box). The text box at the upper middle of Radiocomm will change to green and tell you that things were successful (if you scroll down a bit, that is) Go ahead and reboot your phone, it should be all set.
And thats all. I personally have noticed a definite increase and sustained rate of download speeds when in a high speed 3G area versus having the speeds jump around often
This work on my Motorola Droid pro Verizon!!!
thanks, i got more than twice the signal i had before. This should be sticky!
Ok, this is what I did:
set RootExplorer
find the file /system/build.prop
enter file with editor and find line:
ro.mot.phonemode.vzwglobalphone=0
and change it to
ro.mot.phonemode.vzwglobalphone=1
Save and exit.
Then, from Phone diler dial *#*#4636#*#* to enter servis menu.
Go to phone information.
From "set your preferred network type" I set GSM only. Then go to your phone home, do flight mode on then off.
I get my signal good now, I will experiment these days but so far, all good.
Edit: I have problems with internet (3G) now
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
He guys I tried and found out some tweaks.I modified a bit so that it works well with our Z .
1.U need to root ur phone
2.download root evplorer
3.put this in buildprop.
#Battery improvements pm.sleep_mode=1 ro.ril.disable.power.collapse=0 persist.sys.shutdown.mode=hibernate wifi.supplicant_scan_interval=180
I AM NOT RESPONSIBLE FOR ANY DAMAGE OF UR PHONE OR BATTERY ****DO IT AT UR OWN RISK***--
Satyajit .
Instruction unclear, my underwear upgraded to 4.4
what do?
the only one that still works in the 21st century is wifi scan interval, and thats not needed
the others don't even have supported code anymore..
have a read of http://www.jeffmixon.com/examining-build-prop-tweaks-android-ics-comprehensive-guide-part-2/
You've barely even explained it. Why should we even do this? You haven't given us any stats, improvements, anything at all.
Thread cleaned, as it only served the purpose to spam the forum
So I had recently flashed the latest Resurrection Remix 5.5.8 Lollipop onto my LG G2 VS980 and then continued on to installing the Llama Sweet Kernel R3 and had changed the settings to what the OP said to in his post:
Personal setting (soon as i know how to do i'll make them as default) :
CPU MAX FREQ 1497 MHz
CPU MULTICORE POWER SAVING aggressive
CPU GOV Nightmare
ENABLE Intellithermal (IMPORTANT)
CPU VOLT -20
IO Read-Ahead size 2048 KB and Scheduler ZEN
GPU GOV simple_ondemand
Sound +3 for Headset boost and +2 for Speaker boost
POWER SUSPEND kernel mode
FAST CHARGE enable
WIFI SCAN interval 150 sec
http://forum.xda-developers.com/showpost.php?p=61078624&postcount=2
Click to expand...
Click to collapse
I did that and it worked out perfectly fine and my phone has no issues at the moment, but for some odd reason the double tap to wake feature has been removed/doesn't work anymore. I have gone under Settings and through all the options but there is no option to "Double-tap to wake up" anymore. Is there a solution to this?
------------------------------------------------------------------------------------------
I have found out that it is a problem with the kernel. But is there a way to get around and enable the double tap to wake feature on this kernel? I want to try out the kernel but want the feature on my phone as well. If there is no way of that, then can someone link me to the stock kernel for this rom?
http://forum.xda-developers.com/showpost.php?p=62738195&postcount=7092
This is my first time delving into debugging an android app, so I'll cut right to it in case I am mistaken.
Recently flashed 930U firmware on my 930V (Verizon S7 just to be 100% clear) with root eng, the delag/debloat fixes, Xposed, Greenify, Amplify, etc....
Like everyone else I was experiencing battery drains and heat issues with my phone, so I loaded up adb logcat and threw some awk and sed at it to try and make sense of all the output when I noticed the following entry:
99678:09-01 18:06:24.062 1433 2804 W ActivityManager: Scheduling restart of crashed service com.samsung.android.spayfw/.core.hce.SPayHCEService in 1000ms
So I decided to reboot my and start grabbing logs from the moment it was up and running. I captured logs on my device from 09-01 18:34:35.158 to 09-01 18:39:55.866 and this is what I was able to glean:
$ grep -c 'Scheduling restart of crashed service com.samsung.android.spayfw' spay.log
276
$ egrep -c 'ActivityManager: Process com.samsung.android.spayfw \(pid .*\)\(adj .*\) has died\(.*\)' spay.log
138
So in the course of approximately 5 minutes it appears ActivityManager is attempting to restart Samsung Pay and it's respective framework/service dependencies about every second. For brevity sake here is what it was attempting to restart:
09-01 17:20:30.314 1433 2781 D ActivityManager: isAutoRunBlockedApp:: com.samsung.android.spayfw, Auto Run ON
09-01 17:20:30.314 1433 2781 W ActivityManager: Scheduling restart of crashed service com.samsung.android.spayfw/com.samsung.android.analytics.AnalyticFrameworkService in 1000ms
09-01 17:20:30.314 1433 2781 W ActivityManager: Scheduling restart of crashed service com.samsung.android.spayfw/.core.hce.SPayHCEService in 11000ms
09-01 17:20:30.314 1433 2781 W ActivityManager: Scheduling restart of crashed service com.samsung.android.spayfw/.core.PaymentFrameworkService in 21000ms
09-01 17:20:30.324 1433 7465 D BatteryStatsDumper: WARNING! Cputime is more than 10 seconds behind Foreground time
09-01 17:20:30.324 1433 7465 D BatteryStatsDumper: WARNING! Cputime is more than 10 seconds behind Foreground time
09-01 17:20:30.324 2397 2397 D KeyguardFingerPrint: scheduleStrongAuthTimeout(canceled mStrongAuthNotTimeOutPendingIntent)
This would explain the high wakelocks from ContextManagerWakeLock as well as the number of service calls to the PendingIntentCallbackService I was seeing in the red constantly in Amplify -- even when I was running the stock 930V (PE1). I ended up force-stopping both Samsung Pay and the Samsung Pay Framework and freezing them both from starting up. Here is what I grabbed after rebooting my device with both apps frozen taken from 09-01 18:40:45.822 - 09-01 19:10:11.901:
$ grep -c 'Scheduling restart of crashed service com.samsung.android.spayfw' spay-frozen.log
0
Although my phone feels much cooler to the touch I'm not able to scientifically prove it. Would anyone be able to spare a few minutes and post their results of adb logcat as their phone is, then run it again after freezing Samsung Pay and it's Framework? Bonus thumbs up if you do own a temperature gun and can provide reading the passive heat output.
I want to quickly mention that although my phone is flashed and rooted I didn't do anything crazy to my phone short of installing kernel auditor and making the CPU governor interactive and changing the IO scheduler to deadline -- I basically followed the guide in the forum step-by-step to a tee.
Thanks, much appreciated.
For what it's worth I'm going on 2 days now with my battery at 40% after force-stopping and disabling Samsung Pay along with the Samsung Pay framework.
What's your update these days on it? Still running well? I'm having trouble with my S7 and getting the battery life to improve, I don't use Samsung pay since my bank doesn't support it. I'll bite and give this a shot by disabling samsung pay.