Related
Hey guys,
i have a problem when building 4.0.3 from source. When i flash the fresh compiled
OTA package to my device, the device ends in a bootloop stuck at the google logo.
Logcat says:
Code:
I/SystemServer( 238): Power Manager
I/SystemServer( 238): Activity Manager
I/ActivityManager( 238): Memory class: 64
I/SurfaceFlinger( 251): SurfaceFlinger is starting
I/SurfaceFlinger( 251): SurfaceFlinger's main thread ready to run. Initializing graphics H/W...
E/IMGSRV ( 251): :0: PVRSRVBridgeCall: Failed to access device. Function ID:3223086860 (Bad address).
E/IMGSRV ( 251): :0: OpenServices: PVRSRVBridgeCall failed.
E/IMGSRV ( 251): :0: PVRSRVConnect: Unable to open connection.
E/IMGSRV ( 251): :0: OpenPVRServices: Failed to open services connection
E/IMGSRV ( 251): :0: hal_init: Failed to open services (err=-14)
E/IMGSRV ( 251): :0: hal_open: Graphics HAL not initialized
E/FramebufferNativeWindow( 251): couldn't open framebuffer HAL (Not a typewriter)
E/IMGSRV ( 251): :0: hal_open: Graphics HAL not initialized
E/FramebufferNativeWindow( 251): couldn't open gralloc HAL (Not a typewriter)
E/SurfaceFlinger( 251): Display subsystem failed to initialize. check logs. exiting...
I/ServiceManager( 109): service 'sensorservice' died
I/ServiceManager( 109): service 'power' died
I/ServiceManager( 109): service 'entropy' died
D/AndroidRuntime( 259):
D/AndroidRuntime( 259): >>>>>> AndroidRuntime START com.android.internal.os.ZygoteInit <<<<<<
D/AndroidRuntime( 259): CheckJNI is OFF
I don't know whats going wrong. Can it be a kernel problem? I have tried different 4.0.3 kernels from the dev section, but the result is the same.
The device is a GSM device with PRIMEKK15 unlocked bootloader and I9250XXKK6 baseband.
After pulling the latest 4.0.3 sources with repo and setting up the proprietary files i'have compiled the system without errors:
Code:
~/android/4.0.3$ . build/envsetup.sh
~/android/4.0.3$ lunch full_maguro-userdebug
~/android/4.0.3$ make -j4 otapackage
I really don't understand what i am doing wrong ...
Thanks for any suggestions or answers.
i got this problem when I updated my phone using fastboot.
for me, it was an application installed from market. after wipe everything and redo the flash procedure, everything was fine.
don't know if it is the same problem here.
Did you pull in the proprietary files needed for the build?
At least you've got to the boot animation, my ROM fails at the flashing with a status 7 error mentioning the boot.img
PaulW21781 said:
Did you pull in the proprietary files needed for the build?
Click to expand...
Click to collapse
with ./extract-files.sh .correct?
PaulW21781 said:
Did you pull in the proprietary files needed for the build?
Click to expand...
Click to collapse
Yes, the files are pulled from the device ( if you mean the extract_files.sh from the device folder), compilation finishes without errors.
No boot animation, nothing...
Sent from my Galaxy Nexus using XDA App
Now at this point too, bootloops all the time. I think the code is ****ed
Ok, dmesg gave me this:
Code:
<6>[ 5.367248] PVR: Installing MISR with cookie c0833f74
<6>[ 5.367828] PVR: Installing device LISR SGX ISR on IRQ 53 with cookie c79f5700
<6>[ 5.368255] PVR: OSUnMapPhysToLin: unmapping 65535 bytes from c8be0000
<6>[ 5.368469] PVR: SysFinalise: Version string: SGX revision = 1.2.0
<6>[ 5.369171] PVR_K: (FAIL) SGXInit: Incompatible driver DDK revision (785978)/device DDK revision (780209).
<6>[ 5.369537] PVR_K:(Error): PVRSRVFinaliseSystem: Failed PVRSRVDevInitCompatCheck call (device index: 0) [449, drivers/gpu/pvr/pvrsrv.c]
<6>[ 5.370025] PVR_K:(Error): BridgedDispatchKM: Initialisation failed. Driver unusable. [4812, drivers/gpu/pvr/bridged_pvr_bridge.c]
<6>[ 5.552337] max17040 4-0036: online = 1 vcell = 4007500 soc = 77 status = 1 health = 1 temp = 340 charger status = 0
<3>[ 5.643005] init: sys_prop: permission denied uid:1001 name:net.rmnet1.dns1
<3>[ 5.643737] init: sys_prop: permission denied uid:1001 name:net.rmnet1.dns2
<3>[ 5.644287] init: sys_prop: permission denied uid:1001 name:net.rmnet1.gw
<3>[ 5.645263] init: sys_prop: permission denied uid:1001 name:net.rmnet2.dns1
<3>[ 5.645812] init: sys_prop: permission denied uid:1001 name:net.rmnet2.dns2
<3>[ 5.646484] init: sys_prop: permission denied uid:1001 name:net.rmnet2.gw
<6>[ 5.707031] [MODEM_IF] misc_open : umts_boot0
<6>[ 5.707153] omap_hsi omap_hsi.0: HSI clock is now 96000000
<6>[ 5.723510] omap_hsi omap_hsi.0: Entering RX wakeup in 3 wires mode (no CAWAKE)
<6>[ 5.723602] [MODEM_IF] xmm6260_off()
<6>[ 5.723724] [MODEM_IF] xmm6260_on()
<6>[ 5.724456] [MODEM_IF] PA EVENT : reset =0, pa=1
<6>[ 5.724548] [MODEM_IF] umts_ipc0 state changed: OFFLINE
<6>[ 5.835540] [MODEM_IF] PA EVENT : reset =1, pa=0
<6>[ 5.979125] virtio_rpmsg_bus virtio1: creating channel rpmsg-omx addr 0x3c
<6>[ 5.980194] rpmsg_omx rpmsg-omx1: new OMX connection srv channel: 1024 -> 60!
<6>[ 6.087188] PVR_K:(Error): BridgedDispatchKM: Initialisation failed. Driver unusable. [4812, drivers/gpu/pvr/bridged_pvr_bridge.c]
<3>[ 6.094604] init: untracked pid 118 exited
Anyone knows how to fix this issue?
Try reflashing the boot.img created by your build..
Did you also install the binaries from the google http://code.google.com/android/nexus/drivers.html#maguro into your AOSP source before building?
I built my own AOSP rom too, but haven't tried it yet.
also
Cleaning up when adding proprietary binaries
In order to make sure that the newly installed binaries are properly taken into account after being extracted, the existing output of any previous build needs to be deleted with
$ make clobber
Click to expand...
Click to collapse
http://source.android.com/source/building-devices.html
sorry if you did all this - I'm a noob to ASOP building
Did you wipe the device before installing the rom and kernel?
Luxferro said:
Did you also install the binaries from the google http://code.google.com/android/nexus/drivers.html#maguro into your AOSP source before building?
Click to expand...
Click to collapse
Hey man, that was the problem! Thank you very much... I didn't knew that such libraries exist for 4.0.3.
After installing the binaries and recompiling the phone boots up. Thanks again, also to all the people who tried to help me.
m0rph3us said:
Hey man, that was the problem! Thank you very much... I didn't knew that such libraries exist for 4.0.3.
After installing the binaries and recompiling the phone boots up. Thanks again, also to all the people who tried to help me.
Click to expand...
Click to collapse
No problem. Glad I can help
I guess that hopefully means my build would work too if I ever tried it. Was hoping official 4.0.3 OTA would be out by now. I might just have to try my build too.
Sent from my Galaxy Nexus using Tapatalk
I ran the script under /device/samsung/toro/
is that the correct place to run it, or should I be running it somewhere else?
Nevermind, I'm dumb. I read the post and got it now lol
I'm having the same issue, except for the toro (CDMA/LTE) galaxy nexus. Are these steps in the right order?
step 0: make clobber, step 1: run the extract-imgtec-toro.sh and make clobber, step 2: extract-files.sh, step 3: build/envsetup.sh, step 4: make?
jab416171 said:
I'm having the same issue, except for the toro (CDMA/LTE) galaxy nexus. Are these steps in the right order?
step 0: make clobber, step 1: run the extract-imgtec-toro.sh and make clobber, step 2: extract-files.sh, step 3: build/envsetup.sh, step 4: make?
Click to expand...
Click to collapse
you don't need to excessively run make clobber. all it really does is delete the out/ directory.
Here's how I was able to get a fully functional build ($ANDROID_SOURCE is your build dir):
0) make clobber; # just for the initial cleansing
1) cd $ANDROID_SOURCE/device/samsung/toro && ./extract-files.sh
2) run extract-imgtec-toro.sh OUTSIDE of your build directory (in a temporary location)
3) copy the contents of $TEMPDIR/vendor/imgtec/toro/proprietary/* into $ANDROID_SOURCE/vendor/samsung/toro/proprietary/
4) cd $ANDROID_SOURCE; . build/envsetup.sh
5) lunch #pick your desired toro build. Probably full_toro-userdebug
6) make
The reality is that extract-files.sh does everything well, except it doesn't include the gpu drivers (so we copy them manually). The make files that extract-files.sh creates DOES reference the gpu drivers, they're just not extracted by the script.
Messing with extract-imgtec-toro.sh will give you make files that don't reference any of the other binaries. Your image will boot, but won't have much else working.
Good luck!
Thanks for the quick reply. Here's my script, let me know if you see any errors.
The reason I did make clobber after the extract-imgtec-toro was because the documentation on google's site recommended doing that.
export TOP=/home/jab416171/android/dev/aosp
export GNEXTEMP=/home/jab416171/gnexproprietaryfiles
cd $TOP
repo sync
make clobber
adb wait-for-device
cd $TOP/device/samsung/toro && ./extract-files.sh
cd $GNEXTEMP && ./extract-imgtec-toro.sh
cp $GNEXTEMP/vendor/imgtec/toro/proprietary $TOP/vendor/samsung/toro/proprietary/
cd $TOP
source build/envsetup.sh
lunch full_toro-userdebug
make -j5
jab416171 said:
Thanks for the quick reply. Here's my script, let me know if you see any errors.
The reason I did make clobber after the extract-imgtec-toro was because the documentation on google's site recommended doing that.
export TOP=/home/jab416171/android/dev/aosp
export GNEXTEMP=/home/jab416171/gnexproprietaryfiles
cd $TOP
repo sync
make clobber
adb wait-for-device
cd $TOP/device/samsung/toro && ./extract-files.sh
cd $GNEXTEMP && ./extract-imgtec-toro.sh
cp $GNEXTEMP/vendor/imgtec/toro/proprietary $TOP/vendor/samsung/toro/proprietary/
cd $TOP
source build/envsetup.sh
lunch full_toro-userdebug
make -j5
Click to expand...
Click to collapse
I think your cp needs a '/*' after the first proprietary. The object is to copy the contents of one proprietary directory into the proprietary directory of another. Unless I'm mistaken, your cp will copy the proprietary source folder into the proprietary destination folder resulting in a $TOP/vendor/samsung/toro/proprietary/proprietary. Either that or error out because you specified to cp a dir without a -R.
You should certainly run a make clobber after extracting new binaries if you have files from a previous build still lying around. if you've already cleaned it out, then its just redundant (and not hurting anything).
Otherwise it looks good to me! Good luck!
Makes sense on the cp command. I haven't actually run the script yet, and thanks for taking your time to overlook it.
And do I need to run extract-files and extract-imgtec-toro *every time* I want to do a build, or can I just extract them once, and copy them from another location on my drive, or will the files they extract just stay in the repository?
jab416171 said:
Makes sense on the cp command. I haven't actually run the script yet, and thanks for taking your time to overlook it.
And do I need to run extract-files and extract-imgtec-toro *every time* I want to do a build, or can I just extract them once, and copy them from another location on my drive, or will the files they extract just stay in the repository?
Click to expand...
Click to collapse
Just once. I usually just tar up my vendor/samsung/toro directory and keep the tar in a safe location. No more extractions once you have it.
Hello
I am working directly with AT commands on my phone. For example: AT$GSM?\r for the GSM page of the FieldTest application.
I wrote a little app which call the command "AT$GSM?\r". The app is running nicely on a HTC Magic 32 B (CM 7) and a Nexus One (CM 9). Now I installed it on the CM10 on my HTC One X. But I only get the response +CME ERROR: 100.
The detailed "logcat -b radio" output is:
AT$GSM?\r
(t=1357078390)>> AT$GSM?\r
D/HTC_RIL ( 161): TX::> AT$GSM?\r
}/RILJ ( 698): [3691]< OEM_HOOK_STRINGS {UNIAT, +CME ERROR: 100
When I call the RIL through the byte commands I get the error:
< OEM_HOOK_RAW error: com.android.internal.telephony.CommandException: GENERIC_FAILURE
At the moment I use CM9 with baseband-version: 2.1204.119.17
In FASTBOOT is the information:
RADIO-1.1204.105.14
MODEM PATH: OFF
Does anybody has an idea how to solve it?
Felix
Hi Felix,
FelixGroup said:
OEM_HOOK_STRINGS {UNIAT, +CME ERROR: 100
Click to expand...
Click to collapse
Did you ever resolve this?
CME ERROR: 100 is labelled as "unknown" in the 3GPP 27.007 docs, so it means that your script is working but perhaps that AT command/device is not enabled on that device. Usually ATCoP on Qualcomm MSM8960 can be easily customized by OEM. Since HTC love to customize everything, perhaps its a RIL thing. Many RILs can be made to "interpret" AT commands, and thus they either don't reach CP at all, and is faked by RIL in AP, or reformatted or blocked. Basically anything can happen. Did you try some other AT commands and see if something changes.
I think this one is definitely needed for this forum as i am seeing more and more users ask how to logcat. So posting this here.
Here's how to use logcat:
There are two main ways to do a logcat, within android, and through adb.
Logcat within android can be done one of two ways, through a Logcat app:
Here are two good examples are either: aLogcat or Catlog
I prefer catlog, because in my opinion it has a little bit nicer UI. Both of these programs can dump their logs to a txt file, which is very useful for debugging. Or, you can do it in terminal emulator (same rules as running through adb(see below))
From Moscow Desire:
On the other hand, using adb to run logcat, in my opinion is much more useful, because you can start using it when android boots (i.e. once the boot animation appears.)
The code for logcat to output to a file is
Code:
adb logcat > name of problem.txt
you can also do
Code:
adb logcat -f name of problem.txt
how I prefer to do it is this way:
Code:
adb logcat -v long > name of problem.txt
with the -v flag & the long argument, it changes output to long style, which means every line of logcat will be on its own line (makes it a little neater, imo)
Note: When outputting to a file, you will see a newline, but nothing printed, this is normal. To stop logcat from writting to a file, you need to press ctrl+c.
Here's where using logcat (via adb makes life really easy)
Lets say you find a problem you're having after looking at a logcat.
For example:
When I was trying to use a different ramdisk, wifi wouldn't work so I got a logcat that's almost 1300 lines long (a lot of stuff happens in the background)
So if you are searching for an error in the logcat file (it's always e/ for error, f/ for fatal. Those are the two main things that will break a system.)
Code:
D/dalvikvm( 871): GC_CONCURRENT freed 472K, 6% free 10224K/10823K, paused 1ms+6ms
V/AmazonAppstore.DiskInspectorServiceImpl( 871): Available blocks: 21981, Block size: 4096, Free: 90034176, Threshold: 5242880, withinThreshold? true
D/AmazonAppstore.UpdateService( 871): Received action: null from intent: Intent { cmp=com.amazon.venezia/com.amazon.mas.client.framework.UpdateService }
W/AmazonAppstore.UpdateService( 871): Confused about why I'm running with this intent action: null from intent: Intent { cmp=com.amazon.venezia/com.amazon.mas.client.framework.UpdateService }
D/dalvikvm( 890): GC_CONCURRENT freed 175K, 4% free 9375K/9671K, paused 2ms+3ms
V/AmazonAppstore.ReferenceCounter( 871): Reference (MASLoggerDB) count has gone to 0. Closing referenced object.
E/WifiStateMachine( 203): Failed to reload STA firmware java.lang.IllegalStateException: Error communicating to native daemon
V/AmazonAppstore.UpdateService( 871): runUpdateCommand doInBackground started.
V/AmazonAppstore.UpdateService( 871): Running UpdateCommand: digitalLocker
V/AmazonAppstore.UpdateCommand( 871): Not updating key: digitalLocker from: 1334228488057
V/AmazonAppstore.UpdateService( 871): Finished UpdateCommand: digitalLocker
V/AmazonAppstore.UpdateService( 871): Running UpdateCommand: serviceConfig
V/AmazonAppstore.MASLoggerDB( 871): performLogMetric: Metric logged: ResponseTimeMetric [fullName=com.amazon.venezia.VeneziaApplication_onCreate, build=release-2.3, date=Wed Apr 11 13:10:55 CDT 2012, count=1, value=1601.0]
V/AmazonAppstore.MASLoggerDB( 871): onBackgroundTaskSucceeded: Metric logged: ResponseTimeMetric [fullName=com.amazon.venezia.VeneziaApplication_onCreate, build=release-2.3, date=Wed Apr 11 13:10:55 CDT 2012, count=1, value=1601.0]
W/CommandListener( 118): Failed to retrieve HW addr for eth0 (No such device)
D/CommandListener( 118): Setting iface cfg
D/NetworkManagementService( 203): rsp
D/NetworkManagementService( 203): flags
E/WifiStateMachine( 203): Unable to change interface settings: java.lang.IllegalStateException: Unable to communicate with native daemon to interface setcfg - com.android.server.NativeDaemonConnectorException: Cmd {interface setcfg eth0 0.0.0.0 0 [down]} failed with code 400 : {Failed to set address (No such device)}
W/PackageParser( 203): Unknown element under : supports-screen at /mnt/asec/com.android.aldiko-1/pkg.apk Binary XML file line #16
D/wpa_supplicant( 930): wpa_supplicant v0.8.x
D/wpa_supplicant( 930): random: Trying to read entropy from /dev/random
D/wpa_supplicant( 930): Initializing interface 'eth0' conf '/data/misc/wifi/wpa_supplicant.conf' driver 'wext' ctrl_interface 'N/A' bridge 'N/A'
D/wpa_supplicant( 930): Configuration file '/data/misc/wifi/wpa_supplicant.conf' -> '/data/misc/wifi/wpa_supplicant.conf'
D/wpa_supplicant( 930): Reading configuration file '/data/misc/wifi/wpa_supplicant.conf'
D/wpa_supplicant( 930): ctrl_interface='eth0'
D/wpa_supplicant( 930): update_config=1
D/wpa_supplicant( 930): Line: 4 - start of a new network block
D/wpa_supplicant( 930): key_mgmt: 0x4
(mind you, that's 29 lines out of 1300ish, just for example)
I then could do the following with logcat:
Code:
adb logcat WifiStateMachine:E *:S -v long > name of problem.txt
and this will only print out any errors associated with WifiStateMachine, and anything which is fatal, which makes it about a million times easier to figure out what's going on!
In WifiStateMachine:E, the :E = to look for Errors, the full list of options is as follows:
V — Verbose (lowest priority)
D — Debug
I — Info (default priority)
W — Warning
E — Error
F — Fatal
S — Silent (highest priority, on which nothing is ever printed)
You can replace the :E with any other letter from above to get more info.
In order to filter out anything other than what you are looking for (in this case, WifiStateMachine) you must put a *:S after your last command (i.e. WifiStateMachine:E ThemeChoose:V ... ... AndroidRuntime:E *:S)
Sources: http://developer.android.com/tools/help/logcat.html
http://developer.android.com/tools/help/adb.html
Update for windows users:
Thank go to FuzzyMeep Two, Here's what he's posted for windows
(If you used his tool, here's his post, thank him for his work!)
Note : I am just sharing. Original post here.
Great job brother!!You are in the right path for RC :beer::thumbup:
Sent from my Galaxy Nexus using xda app-developers app
keep going on my friend...:good:
Khizar said:
I think this one is definitely needed for this forum as i am seeing more and more users ask how to logcat. So posting this here.
Here's how to use logcat:
There are two main ways to do a logcat, within android, and through adb.
Logcat within android can be done one of two ways, through a Logcat app:
Here are two good examples are either: aLogcat or Catlog
I prefer catlog, because in my opinion it has a little bit nicer UI. Both of these programs can dump their logs to a txt file, which is very useful for debugging. Or, you can do it in terminal emulator (same rules as running through adb(see below))
From Moscow Desire:
On the other hand, using adb to run logcat, in my opinion is much more useful, because you can start using it when android boots (i.e. once the boot animation appears.)
The code for logcat to output to a file is
Code:
adb logcat > name of problem.txt
you can also do
Code:
adb logcat -f name of problem.txt
how I prefer to do it is this way:
Code:
adb logcat -v long > name of problem.txt
with the -v flag & the long argument, it changes output to long style, which means every line of logcat will be on its own line (makes it a little neater, imo)
Note: When outputting to a file, you will see a newline, but nothing printed, this is normal. To stop logcat from writting to a file, you need to press ctrl+c.
Here's where using logcat (via adb makes life really easy)
Lets say you find a problem you're having after looking at a logcat.
For example:
When I was trying to use a different ramdisk, wifi wouldn't work so I got a logcat that's almost 1300 lines long (a lot of stuff happens in the background)
So if you are searching for an error in the logcat file (it's always e/ for error, f/ for fatal. Those are the two main things that will break a system.)
Code:
D/dalvikvm( 871): GC_CONCURRENT freed 472K, 6% free 10224K/10823K, paused 1ms+6ms
V/AmazonAppstore.DiskInspectorServiceImpl( 871): Available blocks: 21981, Block size: 4096, Free: 90034176, Threshold: 5242880, withinThreshold? true
D/AmazonAppstore.UpdateService( 871): Received action: null from intent: Intent { cmp=com.amazon.venezia/com.amazon.mas.client.framework.UpdateService }
W/AmazonAppstore.UpdateService( 871): Confused about why I'm running with this intent action: null from intent: Intent { cmp=com.amazon.venezia/com.amazon.mas.client.framework.UpdateService }
D/dalvikvm( 890): GC_CONCURRENT freed 175K, 4% free 9375K/9671K, paused 2ms+3ms
V/AmazonAppstore.ReferenceCounter( 871): Reference (MASLoggerDB) count has gone to 0. Closing referenced object.
E/WifiStateMachine( 203): Failed to reload STA firmware java.lang.IllegalStateException: Error communicating to native daemon
V/AmazonAppstore.UpdateService( 871): runUpdateCommand doInBackground started.
V/AmazonAppstore.UpdateService( 871): Running UpdateCommand: digitalLocker
V/AmazonAppstore.UpdateCommand( 871): Not updating key: digitalLocker from: 1334228488057
V/AmazonAppstore.UpdateService( 871): Finished UpdateCommand: digitalLocker
V/AmazonAppstore.UpdateService( 871): Running UpdateCommand: serviceConfig
V/AmazonAppstore.MASLoggerDB( 871): performLogMetric: Metric logged: ResponseTimeMetric [fullName=com.amazon.venezia.VeneziaApplication_onCreate, build=release-2.3, date=Wed Apr 11 13:10:55 CDT 2012, count=1, value=1601.0]
V/AmazonAppstore.MASLoggerDB( 871): onBackgroundTaskSucceeded: Metric logged: ResponseTimeMetric [fullName=com.amazon.venezia.VeneziaApplication_onCreate, build=release-2.3, date=Wed Apr 11 13:10:55 CDT 2012, count=1, value=1601.0]
W/CommandListener( 118): Failed to retrieve HW addr for eth0 (No such device)
D/CommandListener( 118): Setting iface cfg
D/NetworkManagementService( 203): rsp
D/NetworkManagementService( 203): flags
E/WifiStateMachine( 203): Unable to change interface settings: java.lang.IllegalStateException: Unable to communicate with native daemon to interface setcfg - com.android.server.NativeDaemonConnectorException: Cmd {interface setcfg eth0 0.0.0.0 0 [down]} failed with code 400 : {Failed to set address (No such device)}
W/PackageParser( 203): Unknown element under : supports-screen at /mnt/asec/com.android.aldiko-1/pkg.apk Binary XML file line #16
D/wpa_supplicant( 930): wpa_supplicant v0.8.x
D/wpa_supplicant( 930): random: Trying to read entropy from /dev/random
D/wpa_supplicant( 930): Initializing interface 'eth0' conf '/data/misc/wifi/wpa_supplicant.conf' driver 'wext' ctrl_interface 'N/A' bridge 'N/A'
D/wpa_supplicant( 930): Configuration file '/data/misc/wifi/wpa_supplicant.conf' -> '/data/misc/wifi/wpa_supplicant.conf'
D/wpa_supplicant( 930): Reading configuration file '/data/misc/wifi/wpa_supplicant.conf'
D/wpa_supplicant( 930): ctrl_interface='eth0'
D/wpa_supplicant( 930): update_config=1
D/wpa_supplicant( 930): Line: 4 - start of a new network block
D/wpa_supplicant( 930): key_mgmt: 0x4
(mind you, that's 29 lines out of 1300ish, just for example)
I then could do the following with logcat:
Code:
adb logcat WifiStateMachine:E *:S -v long > name of problem.txt
and this will only print out any errors associated with WifiStateMachine, and anything which is fatal, which makes it about a million times easier to figure out what's going on!
In WifiStateMachine:E, the :E = to look for Errors, the full list of options is as follows:
V — Verbose (lowest priority)
D — Debug
I — Info (default priority)
W — Warning
E — Error
F — Fatal
S — Silent (highest priority, on which nothing is ever printed)
You can replace the :E with any other letter from above to get more info.
In order to filter out anything other than what you are looking for (in this case, WifiStateMachine) you must put a *:S after your last command (i.e. WifiStateMachine:E ThemeChoose:V ... ... AndroidRuntime:E *:S)
Sources: http://developer.android.com/tools/help/logcat.html
http://developer.android.com/tools/help/adb.html
Update for windows users:
Thank go to FuzzyMeep Two, Here's what he's posted for windows
(If you used his tool, here's his post, thank him for his work!)
Note : I am just sharing. Original post here.
Click to expand...
Click to collapse
I'm happy very happy ... I have little exp with log cat this is my guide ....
Very good another user of Ak team near RC
Sent from my Galaxy Nexus using xda app-developers app
One doubt, I've downloaded catlog and make it run but I don't know where the txt files are stored or what can I do to recover them.
Also the problem I'm experiencing is a random reboot so even if I have catlog running when the reboot occurs, will I be able to recover the log or it will be lost?
Sorry for the noob question but I'm pretty lost here...
binlalo said:
One doubt, I've downloaded catlog and make it run but I don't know where the txt files are stored or what can I do to recover them.
Also the problem I'm experiencing is a random reboot so even if I have catlog running when the reboot occurs, will I be able to recover the log or it will be lost?
Sorry for the noob question but I'm pretty lost here...
Click to expand...
Click to collapse
catlog should have its own folder in data/media where it saves the txt files...
Hello,
I tried some camera apps (Cameringo+, aillis, and ProShot) which had a horizontal level indicator, but all the indicators did not indicate the true horizontal level. It seems that the built-in accelerometer is wrong. Is there any method to calibrate the wrong sensor?
Thanks,
*push*
I have the same problem. I can't play racing games or use cardboard apps. Can anyone help?
best regards
I have the same problem.
More precisely, when I run the "GPS Status & Toolbox" app and the device is stationery, I get a non-zero rotation vector.
GPS Status shows a 3 degrees/second rotation, even when the device is still.
Since it's a brand new unit, I'm likely to return it to Goog.
I have the same problem, but don't know any solution. Seems it's a common problem.
After further investigations, it seems like there is some calibration data that's not being read when the device boots.
If anyone has the same problem and has root, can you:
Post the contents of:
Code:
/persist/sensorcal.json
Code:
/data/misc/sensorcal_saved.json
Then turn off SELinux or patch the SELinux policy (SuperSU required) by either running:
Code:
setenforce 0
OR
Code:
supolicy --live 'allow sensortool devpts chr_file { read write getattr }' 'allow sensortool persist_sensortool_file file { write }'
Then run:
Code:
/vendor/bin/sensortool.bullhead -c gyro
while the phone is still. This will overwrite
Code:
/persist/sensorcal.json
.
And finally post the contents of
Code:
/persist/sensorcal.json
after this modification.
Your gyro should now be functioning correctly until the next reboot.
It looks like Nexus 5X "forgets" to read the calibration data upon boot.
The above procedure will force a recalibration and forces the sensor hub to use the new calibration data.
I'm looking at a way to load the calibration data into the sensor hub without having to recalibrate, but this may need some serious hacking.
Fif_ said:
After further investigations, it seems like there is some calibration data that's not being read when the device boots.
If anyone has the same problem and has root, can you:
Post the contents of:
Code:
/persist/sensorcal.json
Code:
/data/misc/sensorcal_saved.json
Then turn off SELinux or patch the SELinux policy (SuperSU required) by either running:
Code:
setenforce 0
OR
Code:
supolicy --live 'allow sensortool devpts chr_file { read write getattr }' 'allow sensortool persist_sensortool_file file { write }'
Then run:
Code:
/vendor/bin/sensortool.bullhead -c gyro
while the phone is still. This will overwrite
Code:
/persist/sensorcal.json
.
And finally post the contents of
Code:
/persist/sensorcal.json
after this modification.
Your gyro should now be functioning correctly until the next reboot.
It looks like Nexus 5X "forgets" to read the calibration data upon boot.
The above procedure will force a recalibration and forces the sensor hub to use the new calibration data.
I'm looking at a way to load the calibration data into the sensor hub without having to recalibrate, but this may need some serious hacking.
Click to expand...
Click to collapse
Thanks for your post. Inspired by what you said, I found the other guys and myself are having an miscalibrated accelerate sensor. And it's a little bit difficult to calibrate this sensor than the gyro, since a flat table is needed and the back of 5x is not flat (due to the camera).
P.S. can you post the undo command of this?
Code:
supolicy --live 'allow sensortool devpts chr_file { read write getattr }' 'allow sensortool persist_sensortool_file file { write }'
yaoppp said:
Thanks for your post. Inspired by what you said, I found the other guys and myself are having an miscalibrated accelerate sensor. And it's a little bit difficult to calibrate this sensor than the gyro, since a flat table is needed and the back of 5x is not flat (due to the camera).
Click to expand...
Click to collapse
Great to be able to help.
I found it easy to calibrate the accelerometer: just raise the middle and bottom section of the phone over a book. The camera parts can be dangling.
I have since made more discoveries and was able to calibrate the device correctly and have the calibration persist on reboot.
My sensors problems are now gone!
Instructions follow below.
yaoppp said:
P.S. can you post the undo command of this?
Code:
supolicy --live 'allow sensortool devpts chr_file { read write getattr }' 'allow sensortool persist_sensortool_file file { write }'
Click to expand...
Click to collapse
Just reboot. These changes are in memory only.
If you actually want to undo the policy changes without rebooting, run as root:
Code:
supolicy --live 'deny sensortool devpts chr_file { read write getattr }' 'deny sensortool persist_sensortool_file file { write }'
---------- Post added at 04:30 PM ---------- Previous post was at 03:47 PM ----------
After struggling with this for a while, here's the latest update about what I found.
Contrarily about what I wrote earlier on, the Nexus 5X does read the calibration data in /persist/sensorcal.json at boot.
What happens is the calibration procedure (as initiated by /vendor/bin/sensortool.bullhead -c <sensor>) correctly calibrates the sensor, updates the sensor with the new calibration data, then writes the calibration file /persist/sensorcal.json wrong.
That's why running /vendor/bin/sensortool.bullhead -c <sensor> fixes the problem until the next reboot.
So the fix is to edit by hand the /persist/sensorcal.json file, trying to tweak the calibration values, reboot, check the sensor and do that a few times until you have no sensor bias.
Well, you can do it this way (rebooting between every change to /persist/sensorcal.json), or you can look at the next post for an alternate method that does not involve rebooting twenty times.
WARNING: If you make a typo editing /persist/sensorcal.json, like adding a comma where it's not needed or removing one where it's needed, your device will not boot. You will have to get into recovery and fix the file there. What's even worse, a factory reset will not fix a busted /persist/sensorcal.json as /persist is not wiped during factory reset.
DO THIS AT YOUR OWN RISK
Before you make any change to /persist/sensorcal.json:
Make a backup of the file
Make sure you know how to restore that backup from recovery, without Android booting.
Again: a mess up will softbrick your phone.
My particular case:
My gyrometer readings were off. When the device was still, a simple app to report the gyro reading was returning a non-zero value. The device was thinking it was rotating around only one axis.
Needless to say all apps that used the gyro (eg. driving games) were not happy about this.
My original /persist/sensorcal.json file looked like this:
Code:
{
"accel": [
22,
-2,
-8
],
"gyro": [
22,
-9,
-9
],
"proximity": 1
}
}
I started changing the numbers in the gyro section. After changing the "22" to "100" and rebooting, I saw that my original faulty axis was still wrong, but also another axis was now busted.
So I reverted that change, moved on the next number.
Finally I found that the third figure was the one that was corresponding to my busted axis.
I managed to tweak that number until my gyro was reporting no motion at rest.
And now my Nexus 5X's sensors are just fine, and I can play driving games
My final /persist/sensorcal.json looks like this:
Code:
{
"accel": [
22,
-2,
-8
],
"gyro": [
22,
-9,
-73
],
"proximity": 1
}
}
Since the problem is likely to be memory corruption in /vendor/bin/sensortool.bullhead, on your device, a different calibration value may be affected.
If you want to "factory recalibrate the device" (and re-break your sensors), just follow the instructions in post #5.
Rereading /persist/sensorcal.json without rebooting
The method therein allows you to edit /persist/sensorcal.json then have the on-board sensor re-read that file without having to reboot.
Requirements:
A Nexus 5X device (duh)
Busybox installed
Supersu installed
The attached bullhead-reread-sensor-calibration.zip file.
A root shell (either via ADB or with a Terminal app + su)
Instructions:
Unzip bullhead-reread-sensor-calibration.zip under /sdcard. This will create two new files:
bullhead-reread-sensor-calibration
sensortool-writewrap.so
After every change to /persist/sensorcal.json, run in your root shell:
Code:
sh /sdcard/bullhead-reread-sensor-calibration
. You should see:
Code:
supolicy v2.74 (ndk:arm64-v8a) - Copyright (C) 2014-2016 - Chainfire
Patching policy ...
(Android M policy compatibility mode)
-allow:sensortool:devpts:chr_file:read=ok
-allow:sensortool:devpts:chr_file:write=ok
-allow:sensortool:devpts:chr_file:getattr=ok
- Success
resetting target.
sensorhub said: 'Hello, world!'
sensorhub said: 'Found Bosch BMP280 Pressure/Temperature Sensor'
sensorhub said: 'Found Rohm RPR-0521 Proximity/ALS Sensor'
sensorhub said: 'Found Bosch BMI160 Accel/Gyro Sensor'
sensorhub said: 'init: 22 -2 -8, 22 -9 -73, 0.00, 1'
The numbers on the last line will be different for your device.
Your sensor hub's calibration data has been updated. Note that if you had an app actively reading from the sensors, since they were reset, you will need to quit the app and restart it.
Further notes:
The above script makes no permanent changes to your system (but temporarily alters your SELinux policy, a reboot will reset the policy to its secure default).
The script uses an interposition shared library (sensortool-writewrap.so) that was compiled with the Android NDK from the C file source attached. If you're just using this tool, there is no need to download the C file.
Good guide on how to calibrate your sensors manually.
This should help calibrating your sensor manually if you use the method above:
https://docs.google.com/document/d/14uwBu0R7Yv6bwl5Y7CE1vpFWetnSzgs-zt0GwOaDwIg/edit?pref=2&pli=1
If you don't want to go through the Excel route and exporting the data from the phone, the app "Sensor Kinetics Pro" has a low-pass filter option for all sensors.
You can check that your sensor readouts are as close as possible to zero after tweaking /persist/sensorcal.json as explained in the previous posts.
Fif_ said:
The method therein allows you to edit /persist/sensorcal.json then have the on-board sensor re-read that file without having to reboot.
Click to expand...
Click to collapse
Just wanted to thank you for all these instructions. My accelerometer was 5 degrees off in landscape and while the calibration tool did manage to calibrate it correctly (these settings also stuck for me after reboot), it also calibrated the upright position off by 2 degrees. Some quick manual editing thanks to your method and I now have everything calibrated correctly. It was impossible to take a panorama in landscape before this, so I owe you a really big thank you!
CazeW said:
Just wanted to thank you for all these instructions. My accelerometer was 5 degrees off in landscape and while the calibration tool did manage to calibrate it correctly (these settings also stuck for me after reboot), it also calibrated the upright position off by 2 degrees. Some quick manual editing thanks to your method and I now have everything calibrated correctly. It was impossible to take a panorama in landscape before this, so I owe you a really big thank you!
Click to expand...
Click to collapse
Happy it was useful to someone.
I would have thought the problem was more widespread.
Ok, I probably know the answer, but is there any chance to calibrate it without root permissions? Even if it resets after reboot. I have brand new phone without any scratches, I don't want to loose warranty and change it to a perfect shiny brick (at least not yet). I know my luck, it's gonna be just like that.
I've tried to force Google to admit, that this problem affects every (or almost every) single one Nexus 5X and they should at least add calibration option, because sending phone to the service takes time and isn't the best option. They gave me a standard answer to contact the service :good:
productforums.google.com/forum/?utm_medium=email&utm_source=footer#!topic/nexus/2Xkk3X4KvYQ;context-place=forum/nexus (I can't add link as link, I'm not a trusted user )
Yes, root is required.
However, you can unlock the bootloader, root, follow the instructions and calibrate, and then reimage the device and relock the bootloader.
You'll then have a calibrated stock device, which should be covered by the warranty.
Can You tell me which values did You edited? I have 5 degrees off in landscape too and just can't get right value. I think I actually has problem with accel sensor, not with gyroscope.
P.S. Seems like in Android 7.0 there is no /vendor/bin/sensortool.bullhead .
Instead in init.bullhead.sensorhub.rc I found it uses /system/bin/nanoapp_cmd which have little different format like
/system/bin/nanoapp_cmd calibrate gyro
Click to expand...
Click to collapse
But it actually throws me an "Failed to open /dev/nanohub: err=13 [Permission denied]" error, even after I called both
supolicy --live 'allow sensortool devpts chr_file { read write getattr }' 'allow sensortool persist_sensortool_file file { write }
supolicy --live 'allow nanoapp_cmd devpts chr_file { read write getattr }' 'allow nanoapp_cmd persist_sensortool_file file { write }
Click to expand...
Click to collapse
Any ideas? Anyone tried that hack on Android 7.0 stock?
I've just changed values in /persist/sensorcal.json. My tilt was almost 6 degrees and I knew that the y-axis is bad.
My origin values:
Code:
{
"accel": [
21,
-21,
-8
],
"gyro": [
-1,
-9,
-10
],
"proximity": 9
}
I've changed -21 to -31, then reboot and then i had almost 8 degrees error so it was a bad direction. I've changed it to 0 and now it is perfect.
Now my sensorcal.json loks like this:
Code:
{
"accel": [
21,
0,
-8
],
"gyro": [
-1,
-9,
-10
],
"proximity": 9
}
I'm on the stock rom again and it still works.
@Fif_ I have no words to tell you how awesome you are. THANKS!
Denfox said:
Can You tell me which values did You edited? I have 5 degrees off in landscape too and just can't get right value. I think I actually has problem with accel sensor, not with gyroscope.
P.S. Seems like in Android 7.0 there is no /vendor/bin/sensortool.bullhead .
Instead in init.bullhead.sensorhub.rc I found it uses /system/bin/nanoapp_cmd which have little different format like
But it actually throws me an "Failed to open /dev/nanohub: err=13 [Permission denied]" error, even after I called both
Any ideas? Anyone tried that hack on Android 7.0 stock?
Click to expand...
Click to collapse
Just try to disable SELinux entirely with:
Code:
setenforce 0
and then run nanoapp_cmd.
Fif_ said:
Just try to disable SELinux entirely with:
Code:
setenforce 0
and then run nanoapp_cmd.
Click to expand...
Click to collapse
This not works for me unfortunately.
But actually I did calibration by doing values bust.
As a result to compensate 5 degrees at the Y axis I've changed the value in the calibration json on 25 units.
Thanks for a solution! :good:
Hi, thanks, this worked great.
It was tilted almost 7°
As a note I have to modify "accel" section, not "gyro".
Code:
{
"accel": [
27,
-8,
-4
],
"gyro": [
5,
7,
-10
],
"proximity": 8
}
Main post should be as permanent is 5x section
JP
Hi guys, I have the same problem but only in landscape mode. For example if i take a pano in portrait the image is aligned well, while if i try to do it on landscape it's inclined on the right. Which value i have to change in that file?
giorgis91 said:
Hi guys, I have the same problem but only in landscape mode. For example if i take a pano in portrait the image is aligned well, while if i try to do it on landscape it's inclined on the right. Which value i have to change in that file?
Click to expand...
Click to collapse
Some people had to change the gyro section, others the accel section.
Please read the entire thread, make a backup of sensorcal.json, then try to run sensortool/nanoapp_cmd, see if that helps.
I'm using an app to see what I can run in the the terminal for pretty much no permissions to do so but I found out PS works and I get this.....
USER PID PPID VSZ RSS WCHAN ADDR S NAME
u0_a231 12132 9838 2154756 3628 __do_sys_rt_sigsuspend 0 S sh
u0_a231 12134 12132 2226960 4976 0 0 R ps
Is the first one about malware or could it be used to remote control the phone?
Ty