Related
Hi all, I am trying to use the Scripting Layer for Android to make a simple shell script to disable the stagefright player (the thing that causes the bad sound quality in Froyo) I made some progress, but it doesn't seem to work right. Can someone with knowledge of scripts help me? Here's what I have so far:
echo "Disable Stagefright"
su
setprop media.stagefright.enable-player false
exit
echo "Disabled"
The problem is that it never displays Disabled. It just returns to the terminal and gives # for the root prompt. Anyone know how I can get this to run properly or a better scripting language that I could use and help porting this to that language?
I'm just guessing here, but shouldn't "exit" go after "Disabled"? Otherwise the script terminates before the echo line.
Well you'd think so, but even if I do that, the script actually doesn't exit. That's the main problem, and it still won't echo that last line. Its like I can't exit su and the setprop command never goes through. Its a little annoying, because as far as I can tell, I wrote it the way it should go in the terminal app. Thanks for the input, but unfortunately, it doesn't do anything.
So it seems after typing exit in manually will terminate the script. Also, if I don't specify su, the script runs, but from what I can tell it doesn't actually do the setprop. And there's no echo's in the terminal. It runs and says would you like to exit? If I say no, there is absolutely no messages in the terminal.
su opens a new shell. so your script doesnt finish because it spawned a child process (the new shell) and is waiting for that command to finish before the next ones are run.
what you need to do is SUID that script, remove the su and exit, and run it.
SUID allows any program to be run with SuperUser permissions (read:root).
look up how to set a programs SUID bit, you'll need busybox, more specifically, chmod.
its along the lines of "chmod +s script.sh" but id double check to make sure.
Thanks! I don't understand all of that (really I'm pretty new to scripts), but I'll look into it. Hopefully I can get this figured out. I want to make two scripts to make it easy for people with rooted 2.2 to turn on and off the audio fix with one click. I'll post back if I make any progress.
edit: I just realized how easy what you said is. At least, I think its easy. The only thing I'm not sure of is where the scripts are saved to.
nenn said:
su opens a new shell. so your script doesnt finish because it spawned a child process (the new shell) and is waiting for that command to finish before the next ones are run.
Click to expand...
Click to collapse
Oh yeah, duh.
you can put the script anywhere as long as that directory is in your $PATH or, to make things simpler you can just put it in a directory already in the $PATH variable.
to check where you can put your scripts run this little line of code.
echo $PATH
Click to expand...
Click to collapse
you can add to the $PATH, but im not sure how to do that on the phone, only from a linux standpoint.
What you need to do is easy assuming that middle line "setprop media.stagefright.enable-player false" is the correct command. the script would look like this
setprop media.stagefright.enable-player false
echo "Disabled Stagefright"
Click to expand...
Click to collapse
However this does no sort of checking to see if its already disabled, if it is does it cause a problem to disable it again. doesnt let you enable it, you probably would want this. also doesnt check if the software is installed.
take the quoted text, throw it in a file and set the SUID bit and youre off.
nenn said:
you can put the script anywhere as long as that directory is in your $PATH or, to make things simpler you can just put it in a directory already in the $PATH variable.
to check where you can put your scripts run this little line of code.
you can add to the $PATH, but im not sure how to do that on the phone, only from a linux standpoint.
What you need to do is easy assuming that middle line "setprop media.stagefright.enable-player false" is the correct command. the script would look like this
However this does no sort of checking to see if its already disabled, if it is does it cause a problem to disable it again. doesnt let you enable it, you probably would want this. also doesnt check if the software is installed.
take the quoted text, throw it in a file and set the SUID bit and youre off.
Click to expand...
Click to collapse
Yeah, no idea how to work with the PATH on android. I found out the scripts are in sl4a/scripts on the sdcard. I tried to chmod directly there, but it gave me a "Bad mode" error. Looks like once I get the SUID bit done, I'm good to go.
I know it doesn't have any error handling at this point. I'm not too worried about that at this point. If it disables stagefright, then I can edit my enabling script to work and I'll have a pair of scripts to toggle the sound fix on and off. (since when I turn off stagefright it can have undesired effects on the camcorder and other media apps) Thanks a lot for the help. I'll keep trying to figure out the SUID problem. I'm running windows. I have my linux laptop running, but haven't gotten around to installing the Android sdk on it yet.
I just had an idea. Do you think I can copy the scripts to my linux computer, chmod them, and then copy them back? If that would work, that could be the easier way at this point.
Well, I tried doing the chmod +s on linux and then pushing the files back. Not sure if they kept the SUID though. They run without a problem, but it doesn't show up as changing the property. This is really dumb...
Actually setprop does not need superuser permissions. So you could simply issue the echo commands and the setprop line. Done.
Sent from my PC36100 using XDA App
I tried that first. Didn't work. I'm not sure why setprop isn't working in the shell script. So far I tried without su, with su, and changing the SUID (though I'm not sure if it sticks when its pushed back to Android. It seems like such an easy script. This is really annoying. Also, I'm pretty sure you have to have root to use setprop, at least for the use I'm using. I got the command from here: http://forum.xda-developers.com/showthread.php?t=737111
the suid wont stick when you push the file over. to see if the command is being run proper run the setprop and check its return value, i dont think this will work unless youre in a proper shell. i cant seem to find out the command to check the return value.
if the return value is anything other than 0 (zero) there was a problem.
im off for the day, work is over
Yeah, I didn't think it would stick, but oh well. I can't get the return value, but I've been doing a getprop through adb to see if the property was changed, but it never is. The shell runs, but again, no output, just runs and exits.
superlinkx said:
Yeah, I didn't think it would stick, but oh well. I can't get the return value, but I've been doing a getprop through adb to see if the property was changed, but it never is. The shell runs, but again, no output, just runs and exits.
Click to expand...
Click to collapse
Getprop shows you the value of build.prop. The setprop command does not actually change build.prop but rather changes current session settings. The settings will revert upon reboot. That is why setprop has always been touted as a temporary fix. Try this script:
Code:
echo "Disable Stagefright"
adb shell setprop media.stagefright.enable-player false
echo "Disabled"
Edit: If that does not work, insert "cd .." before you exit command in you original script. That's "cd(space).." without the quotes.
Sent from my PC36100 using XDA App
sombdy said:
Getprop shows you the value of build.prop. The setprop command does not actually change build.prop but rather changes current session settings. The settings will revert upon reboot. That is why setprop has always been touted as a temporary fix. Try this script:
Code:
echo "Disable Stagefright"
adb shell setprop media.stagefright.enable-player false
echo "Disabled"
Edit: If that does not work, insert "cd .." before you exit command in you original script. That's "cd(space).." without the quotes.
Sent from my PC36100 using XDA App
Click to expand...
Click to collapse
Ok, I tried the adb shell method, but that still didn't even temporarily change the build.prop. I know that using setprop is temporary, which is one of the reasons I'm using a script. I know that I can pull build.prop, edit the property and push it back, but then I'd have to put up with undesired effects.
I also tried the cd .. method, like so:
Code:
echo "enable stagefright"
su
setprop media.stagefright.enable-player true
cd ..
exit
echo "ENABLED"
(this is my second script that reenables stagefright. I have it turned off right now)
After doing that, I use adb shell from my computer and getprop still shows its false. If I run the command "setprop media.stagefright.enable-player true" from adb shell, it changes properly and shows when I say getprop. I'll probably work on it more tomorrow. Thanks everyone for the suggestions! I appreciate the help, even if it hasn't quite panned out yet.
Anyone else have any ideas? This is so dumb! I know the solution is simple, I just can't think of what it could be.
You can increase the density (sort of like changing monitor resolution) on your screen by simply changing the build.prop file. This gives you more viewing area on your screen. The build.prop file contains many user variables that are editable and one of them is the LCD Density. The lower the number, the higher the resolution. The default value is 240, but by simply changing it to 200, you can increase the resolution and see more emails in your email app, more app listings in the market, more room for widget alignment, crisper graphics, and much more!
UPDATE 03/25/2011: ADDED SCREENSHOTS! (finally)
PERMANENT ROOT SOLUTION:
now that we can do perm root, you can permanently change this by modifying your build.prop file located /system/build.prop. look for ro.sf.lcd_density and modify the number and save and reboot.
Recommended value is 200, though many users like 190. If you are unsure what you like, please try TEST MODE shown below!
Please be sure to download Spare Parts from the Market, and disable Compatibility Mode in the app. This will fix many, many apps from not displaying full-screen, however there are some apps that will not re-size.
This works really well if you pair it with something like Launcher Pro or ADW.Launcher, where you have control over rows/columns and resizing widgets.
Easiest Method -- Go to Market and download one of the LCD Density apps. Search "LCD Density."
Phone-Only Method:
You can use Root Explorer, or any text editor like notepad++ or text edit.
1. Open a File Manager and locate /system/build.prop
2. Make sure "/system" is mounted as R/W (in Root Explorer, click the Mount R/W button at the top.)
2A. MAKE A BACKUP!
3. Open and Edit the file.
4. Find ro.sf.lcd_density=240 and change it to desired value (recommend 200 or 190 for G2).
5. Save the file.
6. Exit and Reboot!
Click to expand...
Click to collapse
If you use a separate text editor, just copy the file to your SDCard, edit it there, and move it back and overwrite the original. I recommend backing up the original just-in-case.
ADB Method:
at the cmd prompt:
1. adb pull /system/build.prop
2. Go to SDK / Tools folder and open build.prop in a text editor (recommend WORDPAD for Windows).
3. Find ro.sf.lcd_density=240 and change it to desired value (recommend 200 or 190 for G2).
4. Save & Exit
5. go back to cmd prompt and type: adb shell mount -o remount,rw /dev/block/mmcblk0p25 /system
6. type: adb push build.prop /system/
7. exit and reboot phone!
Click to expand...
Click to collapse
[Test Mode]
If you just want to play around with the setting for test, you can do something similar to the temp-root method shown below.
Open Terminal Emulator from your phone or use adb shell from your computer:
type: setprop qemu.sf.lcd_density 200 (or 190,etc)
press enter.
type: busybox killall system_server
press enter.
it will reboot quickly with your new display. Just reboot and it'll go back to stock. Once you find something you like, you can edit the real build.prop file.
---------------------------------
[original mod / pre-perm-root]
Below is for use with Visionary temp-root app.
This is basically taken from the LCD Density Changer app and applied to visionary.sh
You can increase the density (sort of like monitor resolution) on your screen by simply changing the build.prop file. Unfortunately, since we have temp-root only, it'll revert back. The LCD Density Changer - Free app lets you modify it without editing the build.prop and uses a hot boot to apply changes...
I wanted to automate it into startup with Visionary so here's what you can put into your visionary.sh file without even having the app:
Code:
setprop qemu.sf.lcd_density XXX #change XXX to 200, 190, etc
busybox killall system_server
Example Visionary.sh script is found on Post 51. This script also contains commands for Ad Block and Overclocking which can be found in separate threads on the forum.
I use "200" for the XXX density. Some people below mention 190 as their favorite number to use. 240 is the default!
note #1: killall command will do a hot reboot of your system.
note #2: you do not need to download the app to do this. you just need visionary app from Modaco/Paul O'Brien, which is on the market.
Here are some written instructions from V1R3Z on Page 3 of this thread if you do not know how to create and push visionary.sh to your device:
http://forum.xda-developers.com/showpost.php?p=8962877&postcount=27
update 10/30:
added mounting to read/write for /system and /data to the script for users who did not have it already in their script. also some people prefer using 190 as oppose to 200.
update 11/02:
removed mounting for the /data folder as it is unneccessary. make sure you use a proper text editor and save in a format the phone can read. it's probably a better idea to make the script on the phone than in windows.
credit goes to appelflap and jdsemler who found these things.
Hey, I gave this a shot but didn't notice a difference. Do you run any other commands in you visionary script? Do you put this at the end?
Update
Checked my build.prop, still set to 240. Never used the setprop command, but notice the property in build.prop doesn't have qemu.
Sent from my T-Mobile G2 using XDA App
I find 190 to work best.
mckinlk said:
Hey, I gave this a shot but didn't notice a difference. Do you run any other commands in you visionary script? Do you put this at the end?
Update
Checked my build.prop, still set to 240. Never used the setprop command, but notice the property in build.prop doesn't have qemu.
Sent from my T-Mobile G2 using XDA App
Click to expand...
Click to collapse
Hi - It doesnt modify the build.prop at all actually. I also have some other commands in my script to control adfree and setcpu, but perhaps adding these commands at the beginning will help:
Code:
su
mount -o remount,rw /dev/block/mmcblkp025 /system
mount -o remount,rw /dev/block/mmcblkp025 /data
Very nice. I just added a gscript to run it. It works like a champ.
Slows down g2 when uninstalled everything was back to normal.
Sent from my T-Mobile G2 using XDA App
I added the r/w to the /data and removed a line that killed the launcher after uninstalling bloatware. One of those steps did the trick. I love it at 190. I was so frustrated with how the resolution was better than the G1 but didn't really give me the impression with everything blown up.
Thanks for the details.
Sent from my T-Mobile G2 using XDA App
mckinlk said:
I added the r/w to the /data and removed a line that killed the launcher after uninstalling bloatware. One of those steps did the trick. I love it at 190. I was so frustrated with how the resolution was better than the G1 but didn't really give me the impression with everything blown up.
Thanks for the details.
Sent from my T-Mobile G2 using XDA App
Click to expand...
Click to collapse
Cool. I'll update the OP with the read-write commands.
Love the mod, thanks for the tip
any idea why after the hot reboot it causes sim checker light to email my location as if someone stole my phone and put in there sim?
Noticed the stolen report too with the kill launcher command. Must mess with the sim card negotiation and trigger something.
Sent from my T-Mobile G2 using XDA App
Forgive the noobisness, but are the icons in the app drawer supposed to look like complete ass with it set @ 190?
Trial and error results
That's what I noticed as well. ADW looks like crap and that's no lie. Some things aren't using the entire screen anymore.
One thing I've learned when it comes to having Android on the HD2 with a lcd_density of 180 is that you have to unmark compatability mode within spare parts. Since we g2 users don't have that app, we're kinda stuck.
BUT WAIT! Spare parts is on the market. Install it and then do an adb shell...
su
busybox killall system_server
AND IT DIDN'T WORK!!!
So I guess I'm gonna have to try a different density other than 190...
UPDATE:
changing the density to 200 made ADW look fantastic. Some apps still don't use the entire screen. Maybe rebooting entirely will help and actually adding these lines to visionary.sh instead of just running the commands through a shell...
UPDATE2:
Rebooting did nothing. Spare parts doesn't do anything so my question would be How do we get all apps to span across all of the screen?
My example is Weather and Toggle Widget with the Weather Forecast Add-on, the weather animation uses only half of the screen...
minotauri said:
I also have some other commands in my script to control adfree and setcpu
Click to expand...
Click to collapse
Off topic, I know but what are the commands you use for them?
This would help out a great deal!
UPDATE3:
Something went fishy. visionary.sh doesn't seem to want to work. This is what I have,
su
mount -o remount,rw /dev/block/mmcblk0p25 /system
mount -o remount,rw /dev/block/mmcblk0p25 /data
insmod /data/local/vision_oc.ko pll2_l_val=74
setprop qemu.sf.lcd_density 200
busybox killall system_server
Click to expand...
Click to collapse
Basically, it's everything in the OP with the addition of the oc command.
It was working just fine in the beginning but now it doesn't do the hot reboot unless I manually type killall system_server in adb shell or terminal emulator but oc goes through no problems either way...
I would like some clarification on something...
Is it mmcblk0p25 or mmcblkp025 cause 0p25 is what I did and it worked...
FINAL UPDATE:
So I'm really not sure what I did but with a lot of trail and error, I was able to come up with a working script...
su
insmod /data/local/vision_oc.ko pll2_l_val=74
mount -o remount,rw /dev/block/mmcblk0p25 /system
mount -o remount,rw /dev/block/mmcblk0p25 /data
setprop qemu.sf.lcd_density 200
busybox killall system_server
Click to expand...
Click to collapse
don't edit it in anyway or it won't work. I don't know why...
Sorry for floodin the thread with such a massive post but maybe it will help others. But I still want to know how to add adfree into visionary.sh so I don't have to start that up every time to0. If anyone want to throw me the command you used, I will guinea pig it into the script I just created and post it for the for everyone as well.
It's off topic but at least it will be out in the open cause I didn't see it anywhere. I know how to search...
Thank you all!
Launcherpro @ 200 looks amazing. Will keep it like that, it's like a whole new phone.
edit: thinking it's just a stock launcher problem with rendering, cause stock launcher looked like crap @ 200 too
Can someone post a couple of screen shots?
I'm using launcher pro @ 205. Looks amazing, everything aligned. I think you also need to play with your desktop columns and rows. I'm using 5x6 and manually resized widgets.
Thanks a ton to the OP. I absolutely LOVE high resolutions. Im using a density of 190 on ADW, and it looks fantastic! For some strange reason 200 and 210 were crashing the phone, 190 is running smoothly with no problems/glitches.
Sent from my overclocked T-Mobile G2 using XDA App.
Launcher Pro @ 190. This works great. Thank you.
Sent from my T-Mobile G2 using Tapatalk
I use launcher pro. but I know adw works too because I used that in the past with cyanogenmod on nexus one. you will want to change to column and row settings to full optimize the new screen density.
Sent from my T-Mobile G2 using XDA App
I can't get it to work I pushed the script and it was successful I can see it in terminal but it's not setting my density.
PlatinumMOTO said:
I can't get it to work I pushed the script and it was successful I can see it in terminal but it's not setting my density.
Click to expand...
Click to collapse
Reboot device and run visionary...
I found out that the proximity sensor on my Note II isn't working as it should. Whenever I am on call, the screen goes off, but doesn't lit up when I move the phone away from my ear. I've investigated and found that calibrating the proximity sensor could solve the problem.
I've searched around but haven't found the right steps to calibrate the proximity sensor on Note 2. The 'Phone Tester' app shows weird behavior of the sensor. It sometimes just keeps waiting for the data and sometimes shows 'Far' , 'Near' status correctly. But once I move my hand near the sensor and then move it away, the status remains 'Near'.
I'd really appreciate recalibration procedure & any other recommended fix.
I would like to know the solution too
Handwritten from my Note 2
I have same problem too
Sent from my GT-N7100 using xda app-developers app
CrazyEngineer said:
I found out that the proximity sensor on my Note II isn't working as it should. Whenever I am on call, the screen goes off, but doesn't lit up when I move the phone away from my ear. I've investigated and found that calibrating the proximity sensor could solve the problem.
I've searched around but haven't found the right steps to calibrate the proximity sensor on Note 2. The 'Phone Tester' app shows weird behavior of the sensor. It sometimes just keeps waiting for the data and sometimes shows 'Far' , 'Near' status correctly. But once I move my hand near the sensor and then move it away, the status remains 'Near'.
I'd really appreciate recalibration procedure & any other recommended fix.
Click to expand...
Click to collapse
I think from check list call *#0*#:laugh:
Did any of you figure out a fix to this issue?
To calibrate the proximity sensor you need to edit the build.prop, file. Quickest way I do this is by using Romtoolbox pro which has that option. Once in the build prop up editor you'll see the option to recalibrate the proximity sensor. You'll need root access.
Sent from the Rabbit Hole
bushako said:
To calibrate the proximity sensor you need to edit the build.prop, file. Quickest way I do this is by using Romtoolbox pro which has that option. Once in the build prop up editor you'll see the option to recalibrate the proximity sensor. You'll need root access.
Sent from the Rabbit Hole
Click to expand...
Click to collapse
Where exactly in the build.prop is this setting. I access it using root explorer and scanned through the entire file and saw nothing that would hint at the proximity sensor calibration.
rumy said:
Where exactly in the build.prop is this setting. I access it using root explorer and scanned through the entire file and saw nothing that would hint at the proximity sensor calibration.
Click to expand...
Click to collapse
Sent from the Rabbit Hole
bushako said:
Sent from the Rabbit Hole
Click to expand...
Click to collapse
I don't have that in my build.prop I am running ARHD9.0
What exactly does that do. Does it just delay the screen from going of when on your face? In that case I have already disabled the proximity sensor during calls.
I am starting to wonder if this is a hardware fault.
Can you try this? If you use and it does not work once removing it will restore your factory values.
http://db.tt/C7PJnQgt
Sent from my GT-N7100 using xda premium
It looks like the proximity threshold is set too low in the kernel and causes this to misbehave when the sensor gets a little dirty.
For example: If you open the diagnostic menu by dialing *#0*# and look under sensors if your ADC value for the sensor is anything over 12, the proximity sensor will register that something is close to the phone. That value can be temporarily adjusted by setting prox_thresh under /sys/devices/virtual/sensors/proximity_sensor to something higher (like 30).
Unfortunately, it looks like changing this value doesn't "stick" and the next time the sensor is accessed, something changes it back to the default of 12.
I'm guessing that the default value is set in the kernel at compile time. Maybe someone can talk of the kernel devs into tweaking the value.
anyone found a solution to this yet?
Hi, is rooting the phone the only way to get this working? So annoying... Maybe will just send this galaxy note 2 back for a refund, tried for a long time to get this fixed, I think it started after the last android update I thought they'd have done something about it by now...
On Samsung devices like i9100 (Galaxy S3) or N7100 (Note II) you can do the following if you have root permissions:
On Android Terminal App or adb shell do:
Code:
$ su
$ echo 0 > /sys/class/sensors/proximity_sensor/prox_cal
$ echo 1 > /sys/class/sensors/proximity_sensor/prox_cal
The zero resets the actual calibration offset.
The one does an auto calibration (read sensor value, set offset to this sensor value, write calibration offset to "/efs/prox_cal" which is read while device is booting).
Best for calibrate your sensor is to keep it dark, the glass have to be clean and the sensor free (so that the sensor doesn't measure anything).
The calibration offset is stored in efs, thats why you can make full wipe and use other ROMs without the need of recalibration.
You can check the running config by:
Code:
$ cat /sys/class/sensors/proximity_sensor/state
The first value is the calibration Offset, the second one is the sensor threshold (threshold is set at compile time).
Open *#0*# to see "sensors" and check if your proximity sensor is now working properly.
Because in Kernel code (copyright by Samsung) for the device driver is somthing like this autocalibration, i bet that there is a secret menue or code that does the calibration too. But until someone discovers this secret we have to have root permissions to do a proximity sensor calibration.
greaty said:
On Samsung devices like i9100 (Galaxy S3) or N7100 (Note II) you can do the following if you have root permissions:
On Android Terminal App or adb shell do:
Code:
$ su
$ echo 0 > /sys/class/sensors/proximity_sensor/prox_cal
$ echo 1 > /sys/class/sensors/proximity_sensor/prox_cal
The zero resets the actual calibration offset.
The one does an auto calibration (read sensor value, set offset to this sensor value, write calibration offset to "/efs/prox_cal" which is read while device is booting).
Best for calibrate your sensor is to keep it dark, the glass have to be clean and the sensor free (so that the sensor doesn't measure anything).
The calibration offset is stored in efs, thats why you can make full wipe and use other ROMs without the need of recalibration.
You can check the running config by:
Code:
$ cat /sys/class/sensors/proximity_sensor/state
The first value is the calibration Offset, the second one is the sensor threshold (threshold is set at compile time).
Open *#0*# to see "sensors" and check if your proximity sensor is now working properly.
Because in Kernel code (copyright by Samsung) for the device driver is somthing like this autocalibration, i bet that there is a secret menue or code that does the calibration too. But until someone discovers this secret we have to have root permissions to do a proximity sensor calibration.
Click to expand...
Click to collapse
Hey, I've been looking for a fix for prox sensor on my Note 2 ever since I installed Paranoid back in december/january, went back to stock and it was still broken. This fixed it!! So thank you I have just one issue, it seems to go back to being broken when I reboot the phone. Is there any way to prevent this? Also the *#0*# doesn't work for me and the cat command returns just a 0. Thanks.
EDIT: it might help to note that I'm running cyanogenmod 10.1 nightly now
EDIT2: I figured it out! I did a search for prox_cal and found one in /sys/devices/virtual/sensors/proximity_sensor with the values 18,9. i put those values in the empty /efs/prox_cal. It now works on boot.
marcmy said:
... it seems to go back to being broken when I reboot the phone. Is there any way to prevent this? Also the *#0*# doesn't work for me and the cat command returns just a 0. Thanks.
EDIT: it might help to note that I'm running cyanogenmod 10.1 nightly now
EDIT2: I figured it out! I did a search for prox_cal and found one in /sys/devices/virtual/sensors/proximity_sensor with the values 18,9. i put those values in the empty /efs/prox_cal. It now works on boot.
Click to expand...
Click to collapse
I described the sensor recalibration on Samsung rom or Samsung based roms. " *#0*# "is a "secret code" that starts a samsung test tool - only included in stock or stock rom based.
I have read from other users that "cat state" returns zero. I don't know exactly why. But it could be because:
1. that the sensor is powered down (on my phone the sensor never sleeps)
2. the calibration offset is too high
3. the calibration offset is optimal
To test the sensor is on and working you should read the value with finger put on. (there should be value around 127-calibration offset). I guess to do the calibration/sensor reading with display on and phone unlocked. Another user told me that it helped to start an app which reads the sensor values (so the sensor wake up).
But in your case proximity_sensor with the values 18,9 means that the sensor is already calibrated to 18 which can cause a zero at "cat state".
Note that the offset is read from file calibration file at boot time and from that on holded in ram. The RAM value can only be influenced by "/sys/class/sensors/proximity_sensor/prox_cal" or by calibration file (on boot). The auto calibration process not only try to create a /efs/prox_cal file but also changes the calibration value in ram at run time .
So if you try "echo 0 > /sys/class/sensors/proximity_sensor/prox_cal; echo 1 > /sys/class/sensors/proximity_sensor/prox_cal" -> "mmh auto calibration does not work there is no prox_cal file, i will try it manually" can be the wrong way because the calibration offset can be already changed to a calibrated value and so you wont get the correct blank value read out "state".
The other path in virtual filesystem to the sensor control you mentioned is also correct. I don't know which is the most common one.
But since both pathes are available in samsung stock i guess it should be " /sys/devices/virtual/sensors/proximity_sensor".
Be careful of putting in the calibration value manually. In Samsung stock rom the kernel which is reading the calibration value at boot time don't make a character conversion. So if you write the config file like this:
Code:
echo '18,9' > /efs/prox_cal
Ends Up with Calibration value of 49 because the kernel will read the first byte of file. This is a "1" which is the ASCII code for "0x31" which is 49 in decimal. That should work too but throw away half of the sensor sensivity.
If you would like to calibrate it manually you have to:
Code:
cd /sys/devices/virtual/sensors/proximity_sensor/
Read the blank value ( glass have to be clean and fingers away from sensor ).
Code:
$ cat state #finger on the sensor to test if the sensor is working properly
120
$ cat state #blank value
10
Read the actual configuration:
Code:
$ cat prox_cal
0,9
The first value is the "sensor offset" and the second one is "Cancelation Threshold" (threshold can not stored in calibration file)
So you calculate your calibration value: 0 (actual sensor offset) + 10 (blank value) = 10 (new offset) = 0x0a HEX. Make shure your efs partition is mounted writeable and then:
Code:
$ su
$ echo -en $'\x[B]0a[/B]' > /efs/prox_cal
$ sync
If the prox_cal is created first you should change the permisssions. Kernel sets 666 by default :
Code:
$ chown system:system /efs/prox_cal
$ chmod 644 /efs/prox_cal
$ sync
After reboot you can confirm the calibration
Code:
$ cat /sys/devices/virtual/sensors/proximity_sensor/prox_cal
10,9
$ cat /sys/devices/virtual/sensors/proximity_sensor/state
0
If you have to calibrate to a lower sensor value and want to do it the "manual way" you have to reset the calibration or delete the calibration file and reboot. because state value = sensor value - offset . And if offset gets to big the state is alway zero.
greaty said:
On Android Terminal App or adb shell do:
Code:
$ su
$ echo 0 > /sys/class/sensors/proximity_sensor/prox_cal
$ echo 1 > /sys/class/sensors/proximity_sensor/prox_cal
The zero resets the actual calibration offset.
The one does an auto calibration (read sensor value, set offset to this sensor value, write calibration offset to "/efs/prox_cal" which is read while device is booting).
Click to expand...
Click to collapse
working great on my i9505 thanks !!!!
Hello, so I had a very similar experience in flashing Paranoid and then my sensor went bezerk. It seems to be just not turning on with the phone, but the front camera does work fine. I was able to get it working a few days ago by flashing the stock rom and kernel multiple times, but I decided to get bold and reflash the Neak kernel and poof, that was over. Not another few flashes would bring my sensor back. At this point I don't even know what to do.
Thought it might also be worthwhile to mention: the light sensor also does not work and when I looked through the files in the sys/class/sensors for both proximity and light sensors the runtime status is unsupported.
A full Odin restore should reset all these values and the whole thing should work right immediately as long as the sensor hardware hasn't gone bad, right?
Easy FIX!!!!!
I took a can of compressed air and blew it through the top earpiece grill a few times and Voila, it works great now!!
I actually used a Old perfume can which perfume was over and it was only pressing Gas OFF!! :good::good::good::good:
Finally Fixed My Sensor
greaty said:
I described the sensor recalibration on Samsung rom or Samsung based roms. " *#0*# "is a "secret code" that starts a samsung test tool - only included in stock or stock rom based.
I have read from other users that "cat state" returns zero. I don't know exactly why. But it could be because:
1. that the sensor is powered down (on my phone the sensor never sleeps)
2. the calibration offset is too high
3. the calibration offset is optimal
To test the sensor is on and working you should read the value with finger put on. (there should be value around 127-calibration offset). I guess to do the calibration/sensor reading with display on and phone unlocked. Another user told me that it helped to start an app which reads the sensor values (so the sensor wake up).
But in your case proximity_sensor with the values 18,9 means that the sensor is already calibrated to 18 which can cause a zero at "cat state".
Note that the offset is read from file calibration file at boot time and from that on holded in ram. The RAM value can only be influenced by "/sys/class/sensors/proximity_sensor/prox_cal" or by calibration file (on boot). The auto calibration process not only try to create a /efs/prox_cal file but also changes the calibration value in ram at run time .
So if you try "echo 0 > /sys/class/sensors/proximity_sensor/prox_cal; echo 1 > /sys/class/sensors/proximity_sensor/prox_cal" -> "mmh auto calibration does not work there is no prox_cal file, i will try it manually" can be the wrong way because the calibration offset can be already changed to a calibrated value and so you wont get the correct blank value read out "state".
The other path in virtual filesystem to the sensor control you mentioned is also correct. I don't know which is the most common one.
But since both pathes are available in samsung stock i guess it should be " /sys/devices/virtual/sensors/proximity_sensor".
Be careful of putting in the calibration value manually. In Samsung stock rom the kernel which is reading the calibration value at boot time don't make a character conversion. So if you write the config file like this:
Code:
echo '18,9' > /efs/prox_cal
Ends Up with Calibration value of 49 because the kernel will read the first byte of file. This is a "1" which is the ASCII code for "0x31" which is 49 in decimal. That should work too but throw away half of the sensor sensivity.
If you would like to calibrate it manually you have to:
Code:
cd /sys/devices/virtual/sensors/proximity_sensor/
Read the blank value ( glass have to be clean and fingers away from sensor ).
Code:
$ cat state #finger on the sensor to test if the sensor is working properly
120
$ cat state #blank value
10
Read the actual configuration:
Code:
$ cat prox_cal
0,9
The first value is the "sensor offset" and the second one is "Cancelation Threshold" (threshold can not stored in calibration file)
So you calculate your calibration value: 0 (actual sensor offset) + 10 (blank value) = 10 (new offset) = 0x0a HEX. Make shure your efs partition is mounted writeable and then:
Code:
$ su
$ echo -en $'\x[B]0a[/B]' > /efs/prox_cal
$ sync
If the prox_cal is created first you should change the permisssions. Kernel sets 666 by default :
Code:
$ chown system:system /efs/prox_cal
$ chmod 644 /efs/prox_cal
$ sync
After reboot you can confirm the calibration
Code:
$ cat /sys/devices/virtual/sensors/proximity_sensor/prox_cal
10,9
$ cat /sys/devices/virtual/sensors/proximity_sensor/state
0
If you have to calibrate to a lower sensor value and want to do it the "manual way" you have to reset the calibration or delete the calibration file and reboot. because state value = sensor value - offset . And if offset gets to big the state is alway zero.
Click to expand...
Click to collapse
Finally, this fixed my problem. I don't know why, but the other solution worked one time while using a CM 10.2 nightly
Code:
$ su
$ echo 0 > /sys/devices/virtual/sensors/proximity_sensor/prox_cal
$ echo 1 > /sys/devices/virtual/sensors/proximity_sensor/prox_cal
But, when I upgraded to the latest nightly, this stopped working. It wouldn't work even if y restored my stock ROM backup using TWRP, I even flashed a stock image with odin and the sensor would still malfunction.
Today I followed this steps using the values returned for my phone and it finally worked! I did this.
Code:
$ cat state #finger on the sensor to test if the sensor is working properly
120
$ cat state #blank value
10
This returned 255 #finger on the sensor and 69 #blank value
and when I did
Code:
cat /sys/devices/virtual/sensors/proximity_sensor/prox_cal
this returned 47,60,45.....so my offset was 47. Ths sum of offset and #blank value was 47 + 69 = 116 that is equal to 74 in HEX.
so I did
Code:
$ echo -en $'\x74' > /efs/prox_cal
and then
Code:
$ chown system:system /efs/prox_cal
$ chmod 644 /efs/prox_cal
$ sync
After that I rebooted my phone from the terminal using que command
Code:
$ reboot
and that was it! Now my sensor is fixed and survives reboot. Thanks!
Hi Guys,
I have a Samsung Galaxy S3 SGH-T999 (Tmobile). When I had the stock ROM the phone worked fine, but now I am having the same issue with multiple ROMs.
Whenever I make or receive a phone call, the screen turns black (LED off and everything) and it will not come back on until the other person has hung up (I can't, because I have no buttons). I have tried Cyanogenmod 10.2.1 stable, Cyanogen mod 11 nightly (newest), and Paranoid Android 4.4.2 BETA 3.
I read on another forum that this may have something to do with the proximity sensor, and I went to settings>devices>more and under "Sensors and Motors" there is only vibrator intensity. I also checked the call app settings and there are not any options relating to proximity sensor. I also tried several USSD codes to check that which I found online but have been unsuccessful in getting any of those to work.
Any help would be greatly appreciated!
Thanks,
EvilWoodchuck
Try a CM 11 Stable (Don't go for latest nightly but the last stable) and recalibrate your Sensors. Make a CLEAN install no restoring apps or data. Also do you happen to have any Kernel tweaks of any sort ?
Last but not least, try a single light tap on Power button. That will bring the screen back.
If that fails, odin full stock firmware to see if it helps. If not its likely a faulty sensor. Easy and cheap to fix surprisingly.
Sent from my SGH-T999 using Tapatalk
Perseus71 said:
Try a CM 11 Stable (Don't go for latest nightly but the last stable) and recalibrate your Sensors. Make a CLEAN install no restoring apps or data. Also do you happen to have any Kernel tweaks of any sort ?
Last but not least, try a single light tap on Power button. That will bring the screen back.
Click to expand...
Click to collapse
Got it working, had to manually recalibrate the proximity sensor with terminal emulator. Thanks for the help guys
Edit:
I am not able to post links yet, but here is the method used for recalibration if anyone needs it (credit to Viraj Kshatriya of androidlegend.com):
Prerequisites:
1. Enable USB Debugging
2. Root Access
3. Terminal Emulator
All commands will be done in terminal emulator as Root:
1. Enter superuser mode
su <enter>
2. Obtain offset value
cat /sys/devices/virtual/sensors/proximity_sensor/prox_cal <enter>
This will return a few numbers, the first one is your offset value
3. Obtain normal value
cat /sys/devices/virtual/sensors/proximity_sensor/state <enter>
This will return one number, this is your normal value
4. Modify /efs/prox_cal
Take your offset value, and add it with your normal value
Convert sum of these to hexadecimal
echo -en $ '\x**' > /efs/prox_cal (** being your hexadecimal number from above step) <enter>
chown system:system /efs/prox_cal <enter>
chmod 644 /efs/prox_cal <enter>
sync <enter>
reboot <enter>
5. Wait for phone to reboot and you should be good to go!!! :good:
EvilWoodchuck
Care to share how you did that exactly? Good job getting it to work!
I am curious and im sure itll help others in the future though.
Sent from my SGH-T999 using Tapatalk
See edit
Sent from my SGH-T999 using xda app-developers app
Yesterday, @dproldan and I were editing my build.prop file for the 360. I figure that this might be a good thread to talk about what you have done with your build.prop and what it does.
ro.ambient.enable_when_plugged=false
and not sure if this is also needed,
ro.ambient.force_when_docked=false
This will turn your screen off when the device is docked.
@dproldan also suggests TRYING the CPU throttling property.
hw.cpu.throttle.state=1
If it doesn't work, just change it back to default.
ALWAYS remember to make a copy of the build.prop before you alter it.
XDA:DevDB Information
[ROOT] All 360 Mods, Device Specific App for the Moto 360
Contributors
abuttino, abuttino
Version Information
Status: Testing
Created 2014-10-17
Last Updated 2014-10-16
Yes! no more worries about the display getting the image persistence issue or the wife complaining about the room being illuminated by the watch.
About the throttle property. It is used in the /init.minnow.rc file, at the end you'll see that when it's not set (0), the max frequency is 1GHz, when it's set (1), the max frequency is 600MHz. It does so by writing a value to /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
The valid frequencies, set in the kernel, are 300MHz, 600MHz, 800MHz and 1 GHz. so you can write directly to that and get a direct result:
Code:
echo 800000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
This doesn't mean that It will use less battery, but it's something to try.
Awesome! Any chance of turning off automatic HRM? I'm really curious how much battery increases since it turns on every 5 min.
HRM?
abuttino said:
HRM?
Click to expand...
Click to collapse
Heart Rate Monitor
I found the name of the apk that needs to be modified for the HRM but I'm not at home to message dproldan
Any way to change the ambient mode to be always on and/or adjust the brightness?
PsychDrummer said:
Awesome! Any chance of turning off automatic HRM? I'm really curious how much battery increases since it turns on every 5 min.
Click to expand...
Click to collapse
We need to edit a Motorola package, but that will take some time.
For the moment, you could disable the constant monitoring with:
Code:
pm disable com.motorola.targetnotif
This will remove the automatic heart monitoring, but also the default watchfaces and the connection to the motorola app in the phone. The rest of the functions are not modified. You can still access the HRM with the google Fit app.
dproldan said:
We need to edit a Motorola package, but that will take some time.
For the moment, you could disable the constant monitoring with:
Code:
pm disable com.motorola.targetnotif
This will remove the automatic heart monitoring, but also the default watchfaces and the connection to the motorola app in the phone. The rest of the functions are not modified. You can still access the HRM with the google Fit app.
Click to expand...
Click to collapse
Thanks! Will running that command with "enable" instead of "disable" reverse it?
Tonight was a very productive night for the 360!
@dproldan and I were on a conversation on the freenode IRC chat #moto360 and he and I have tested some things out that seem to work extremely well.
The first and most requested thing was to disable the unattended heart rate monitor called "Heart Activity"
So, with your rooted watch in a root/su shell prompt type:
pm disable com.motorola.targetnotif/com.motorola.omni.HealthActivity
Now, until we figure out which EXACT activity is using the pedometer, he suggested we kill the fit app altogether by using this command:
pm disable com.google.android.apps.fitness
If you feel that you MUST disable the Heart Rate program that DOES NOT take your heart rate unattended, or use any battery unless you run it yourself:
pm disable com.motorola.targetnotif/com.motorola.omni.HeartRateActivity
I've seen this mentioned a few times and, figure I would at least put it out there for people to try if they need to.
If you need to root your watch, @dproldan is selling a cradle that he designed and, is a LOT more stable than a self built cat5e connector that can short at any time.
http://forum.xda-developers.com/moto-360/development/cradles-moto360-usb-conection-sale-t2901110
The 360 community needs more devs and people willing to test. If you have any requests, solutions please post in this thread. If you need help with rooting your watch; please don't be afraid to post in the Q&A section of the 360 forum.
PsychDrummer said:
Thanks! Will running that command with "enable" instead of "disable" reverse it?
Click to expand...
Click to collapse
Yes.
Just got Rooted and and been doing little mods here and there, some inverted apps and such. The thing I'm having an issue with is writing to system, the keep getting permission failed, is any one else successfully writing to system. I even edited the 360 superboot.Img to install busybox and still no success. If any one has a solution to this I can start adding some cool mods and possible features.
Did you rename it to boot.img?
I just Rooted using the utility, I have root, just if I try pushing something to system I get a permission denied error, samething with adb remount.
Get the boot image from the post here, rename it to boot.img and do this:
"fastboot boot boot.img"
Stick with the tried and true methods
ok ill try that right now. one question are you pushing to system with the adapter or over BT?
Fastboot is always over USB. ADB commands can be done over b/t
steal25 said:
ok ill try that right now. one question are you pushing to system with the adapter or over BT?
Click to expand...
Click to collapse
To push things to /system, you need to make the partition writable. With previous devices, you'de do that with "adb remount", but the moto360 over bluetooth doesn't allow that, AFAIK. We also don't have a root adb yet, so you need to put things in /storage/sdcard0 from the computer, then move them to the final folder from a root shell
What I've been doing is:
Code:
computer: adb -e shell
moto360: su
moto360: mount -o rw,remount /dev/block/mmcblk0p14 /system
moto360: exit
moto360: exit
computer: adb -e push whatever-you-want-to-push /storage/sdcard0/
computer: adb -e shell
moto360: cp /storage/sdcard0/whatever-you-want-to-push /where-you-want-to-place-it
I hope that makes sense. I have only moved simple things yet, but I hope we'll find better ways soon.
You can push the build.prop over Bluetooth and should be able to remount system too. I've done it every time I've edited my build.prop
dproldan said:
To push things to /system, you need to make the partition writable. With previous devices, you'de do that with "adb remount", but the moto360 over bluetooth doesn't allow that, AFAIK. We also don't have a root adb yet, so you need to put things in /storage/sdcard0 from the computer, then move them to the final folder from a root shell
What I've been doing is:
Code:
computer: adb -e shell
moto360: su
moto360: mount -o rw,remount /dev/block/mmcblk0p14 /system
moto360: exit
moto360: exit
computer: adb -e push whatever-you-want-to-push /storage/sdcard0/
computer: adb -e shell
moto360: cp /storage/sdcard0/whatever-you-want-to-push /where-you-want-to-place-it
I hope that makes sense. I have only moved simple things yet, but I hope we'll find better ways soon.
Click to expand...
Click to collapse
Yep makes sense, been driving me nuts, I even edited the Rooted boot . Img to install busybox and it works but when I ran busybox mount..... It returned couldn't find etc/Fstab. I'll do a little more digging when i get home