Database Develop

Compass and Accel sensors not working, Please Help!

I seem to be having an odd problem with my new G1.
In any Cupcake build (JF 1.51, TheDude's 1.2, Official ADP) I flash, neither the compass nor the accelerometer sensors work at all. I have flashed between them several times, with an Alt+W each time, so I know it's not a bad flash.
The strange thing is, when I jump back to an official RC29 build, both sensors work fine. I haven't tried RC30 or anything else, but I know the sensors are physically functional.
I have re-flashed the latest radio as well, as it is currently using 2.22.19.26I.
If anyone can help me with this problem, I would greatly appreciate it.

gigawatts said:
I seem to be having an odd problem with my new G1.
In any Cupcake build (JF 1.51, TheDude's 1.2, Official ADP) I flash, neither the compass nor the accelerometer sensors work at all. I have flashed between them several times, with an Alt+W each time, so I know it's not a bad flash.
The strange thing is, when I jump back to an official RC29 build, both sensors work fine. I haven't tried RC30 or anything else, but I know the sensors are physically functional.
I have re-flashed the latest radio as well, as it is currently using 2.22.19.26I.
If anyone can help me with this problem, I would greatly appreciate it.
Click to expand...
Click to collapse
I think your using the pre-cupcake apps. Did u download the apps after you updated or did you install them from a back up?
Best way to check, You should got to settings and then sounds&display and check off orientation. You phone should switch from portrait to landscape when you rotate any program (except homescreen). If that works then nothing is wrong with your phone. If it doesn't then something happened somewhere weird

any apps i have installed have been after i flashed a rom (after a wipe) and not from a backup. Plus, something as simple as Google Maps or the Browser App should just rotate without opening the keyboard.
Best way to check, You should got to settings and then sounds&display and check off orientation.
Click to expand...
Click to collapse
By that I assume you place the check mark (lit green) next to the option, not "check it off" (not lit green). I have tried both checked and unchecked in pre-installed apps like maps and browser, and still nothing.

Small update. I just flashed JF's v1.43_RC33 with root, keeping the same more recent radio, and both sensors work there, as they do in RC29. It seems to be ONLY cupcake based roms where they don't work.
Any other suggestions anyone has for me? I might try a hero build next, to see if they work there, but I'm not sure how stable they are yet.
Any help/suggestions would be greatly appreciated!

Accelerometer fix
http://forum.xda-developers.com/showpost.php?p=4081673&postcount=4885

I tried your suggestion, and it did not work. Unlike the other user reporting that the sensors would work for a short time after reflashing, mine has never worked after a cupcake flash. Only after a pre-cupcake flash.
Although ideas like that are what I am looking for, possible corrupt config files that need to be cleared or maybe a mod probe command of some sort to activate or wake up the sensors.

Upon some more inspection, I get the feeling something is wrong with my akmd process, or whatever executable generates the akmd_set.txt compass and accelerometer calibration data. I tried to follow some instuctions to purge the akmd_set.txt file to clear any bad config, but the file is no where to be found. My phone doesnt seem to generate one at all when it's booting.
The akmd process does remain running in the background, as here is its ps output:
Code:
# ps | grep akmd
compass 77 1 1320 328 c020d268 afe0c45c S /system/bin/akmd
This is the output I get from logcat when I try to manually run the /system/bin/akmd process or when it restarts automatically after being killed:
Code:
D/AKMD ( 362): akmd 1.6.4 START
D/AKMD ( 362): library version: 1.2.1.1129
D/AKMD ( 362): Compass OPEN
D/AKMD ( 362): No calibration data
D/AKMD ( 362): Can not initial compass parameters error: -5
and this is the output I get when I run a program like Orienteer:
Code:
I/ActivityManager( 90): Starting activity: Intent { action=android.intent.action.MAIN categories={android.intent.category.LAUNCHER} flags=0x10200000 comp={com.deafcode.android.Orienteer/com.deafcode.android.Orienteer.Orienteer} }
I/ActivityManager( 90): Start proc com.deafcode.android.Orienteer for activity com.deafcode.android.Orienteer/.Orienteer: pid=363 uid=10041 gids={}
D/SensorManager( 363): found sensor: AK8976A 3-axis Accelerometer, handle=0
D/SensorManager( 363): found sensor: AK8976A 3-axis Magnetic field sensor, handle=1
D/SensorManager( 363): found sensor: AK8976A Orientation sensor, handle=2
D/SensorManager( 363): found sensor: AK8976A Temperature sensor, handle=3
D/dalvikvm( 363): GC freed 920 objects / 64320 bytes in 92ms
D/LocationManager( 363): Constructor: service = [email protected]
D/Sensors ( 90): sensors=00000005, real=00000005
D/GpsLocationProvider( 90): setMinTime 2000
W/IInputConnectionWrapper( 145): showStatusIcon on inactive InputConnection
I/ActivityManager( 90): Displayed activity com.deafcode.android.Orienteer/.Orienteer: 1313 ms
D/dalvikvm( 145): GC freed 795 objects / 45896 bytes in 165ms
D/GpsLocationProvider( 90): TTFF: 7203
Maybe this will give someone some more insight as to the problem I am having.

hello,
i me french and i have the same problem.
No akmd_set.txt on my phone.
If you are a solution could you partage it ?
I think it's a driver problem but i'm not sure.
JEEP

Unfortuantly I have still not found a solution, but continue to look for one. I will let you know here if I do manage to solve it.

I am also having the same problem. Wiping does not fix it and the method stated by Cyanogen didn't work either. I don't know if this will be any help, but I do know the accelerometer issue started about 3 or 4 days ago for me. Maybe if I list things I've done to my phone in the last few days, it might help narrow down the cause if others with the same issue compare their experiences to each other.
I have a US T-Mobile G1 and I have been rooted since February. Since that time I have upgraded to (and currently use) the latest radio from HTC, Haykuro's SPL, and a class 6 4gb card. I've also been through more roms than I can count in that time, all without an accelerometer issue till now.
Now that I've got all that out of the way here's the more relevant stuff:
Within the last week I have upgraded to Cyanogen's 1.3.1 recovery boot and installed the latest JAC Hero build. I repartitioned my card into 3 partitions with the directions given in JustAnotherCrowd's thread using parted in the recovery's console.
Code:
#parted /dev/block/mmcblk0
rm 1
rm 2
mkpartfs primary fat32 0 3420
mkpartfs primary ext2 3420 3932
mkpartfs primary linux-swap 3932-3964
This is the first time I've ever used apps to sd. After using that rom for about a day, I switched to Cyanogen's build and wiped my user data without wiping the ext partition of my sd card and I continued to use the swap partition on my Cyanogen build. I'm fairly sure but not 100% certain that the accelerometer was still working at this point. Soon after installing this rom, Cyanogen released an update including the compcache modules to replace the linux-swap setup. I installed the custom userinit.sh script to system/sd to activate compcache. Then Cyanogen released another update (immediate bug fixes) almost as soon as I got this rom working. I flashed the update.zip, but then it started to boot loop. I wiped the phone (not the ext partition), still boot looped. I took out the sd, still boot looped. I put the sd card back in wiped again, reflashed, and then clicked "repair ext file system". STILL BOOT LOOPED! (Don't say I just wasn't giving it enough time to boot because I acctually watched the boot animation flicker in and out for a second and start over.) Next, I used fastboot to restore only the user data from a nandroid backup of an older Cyanogen rom. This time it worked. Next, I installed the audio resources to system/sd/media and linked them using the userinit.sh file. The next day, I realized that the accelerometer was no longer functioning.
I hope this description helps to figure this out.

I'm having the exact same issue.

testing567, can you post the userinit.sh file you are currently using, and possibly you or someone else post their userinit.sh of a phone with a working accelerometer and compass here?
I am thinking that one of my init scripts may not be calling the akmd service properly, as in not with the correct permissions or something, and thus not calibrating itself on boot. I was planning on upgrading to the latest cyanogen update today, as i am running 3.6.5 right now. I was also considering upgrading my SPL to a dev SPL so i can use nandroid to backup (getting a little tired of loosing everything when attempting different roms to fix this issue).

I got my userinit.sh from this post.
http://forum.xda-developers.com/showpost.php?p=4140826&postcount=74
I also decided to take advantage of the media symlinking already in this script and pushed the audio resources to system/sd/media/.

I've always had the same issue when upgrading to a cupcake based rom. Nobody else until recently seemed to share my misfortune (sorry for everyone else). There is an exception though, JF 1.5 (T-Mobile) build the sensors work (although miscalibrated). I haven't found any other solutions or any other way to generate the settings file. My process output appears to be the exact same as you've posted.
I'll keep trying some things but I just want to keep this alive incase anyone else needs a fix and one of us comes up with a solution.

RemoteDJ, I may actually have a solution to your miscalibrated problem. In the process of going through and trying to get my sensors working, I created an empty akmd_set.txt file with chmod 777 permissions (just so it wouldnt ***** about some user permissions when trying to edit it), and then rebooted the phone. Upon looking at the file after reboot, it was filled with calibration data.
Although this has not fixed my problem, it may help you. Also, the application "Bubble" has a calibrate sensors menu option, which may help you too. I may have to try reverting back to JF 1.5 to see if I have better luck there. Was that JF 1.51 you were using? If not, please advise.

Yes it was JF 1.51, it's funny because I just got done making a blank chmod 777 akmd_set.txt lol. Of course i'm on the latest stable cm-3.6.8.1 currently and the sensor doesn't work at all.
Just so we stay up to date with each others findings, I also pulled the akmd app from Haykuro's ION, JF 1.43, JF 1.51, Official RC33 and the current CM build. I have only tried replacing the current one with the ION app (in recovery), so far no change, but I think the only file difference I noticed out of the files I pulled was that the JF 1.43 and Official RC33 seemd to be the same (haven't hashed them to verify) and different then the others which seem to be the same but since I haven't hashed any of them to verify yet I can't say for sure.
I am calling it a night right now but will let you know if I find anything tomorrow.
Just a followup with the hash info.. looks like I was correct:
517a87a4e6caa5e66f0520c68dcb7c0e - Official RC33
517a87a4e6caa5e66f0520c68dcb7c0e - JF 1.43
c3a80124ab072f9bf12cc9e4155a0f9f - JF 1.51
c3a80124ab072f9bf12cc9e4155a0f9f - ION
c3a80124ab072f9bf12cc9e4155a0f9f - CM 3.6.8.1
Another Edit: I am apparently not good at going to sleep.. Good News! (semi).
I left the akmd_set.txt in place (it got filled with data just like yours)
replaced ion/cm akmd with jf 1.43 and now the sensor appears to be working (although still miscalibrated for me, this might be a hardware issue.. lots of drops).
step by step.
copy jf1.43 akmd to sdcard (i just pulled it out of the update zip).
reboot recovery
mount /system
rm /system/bin/akmd
mount /sdcard
cp /sdcard/jf1.43_akmd /system/bin/akmd
then umount (probably not required)
reboot.
It still didn't work, but I deleted the akmd_set.txt via adb and then rebooted and voila!
Let me know if any of that works for you
Edit: I was able to fix my calibration by reverting to the rc30 akmd, I have absolutely no idea why my device is so picky, but it only has ever had correct calibration with accelerometer on the rc29/30 builds (this includes all official t-mobile ota releases). Anyway just wanted to through that out there incase anyone else uses the jf1.43 and is miscalibrated.

RemoteDJ,
Thank you so much for that suggestion! That totally worked for me! I flashed cm-3.6.8.1 tonight and replaced its /system/bin/akmd binary with the one from jf 1.42. After messing around with some permissions (I failed to realize the akmd binary was not set as executable when i moved it over ) i was able to create a blank akmd_set.txt, chmod 777 it, and then restart the akmd service (stop akmd, followed by start akmd).
I can not thank you enough for this suggestion! Guess it just took another similar brain bashing away at the same problem to solve it. I just wonder why this is not a problem for a lot of other people out there. It's the same hardware, so you would think everyone upgrading to cupcake would have an incompatible akmd binary. Strange...

Sweet, I'm really glad it worked for you!
I can't imagine for the life of me why other people don't have similar problems, but then again I've had a few problems that seemed indivualized to my device lol. Its only recently that I discovered a few other people were having problems with the accelerometor.
Oh well, all in all just glad this worked.
Maybe we can get Cyanogen to include this in his FAQ as an alternative for sensor repair for the people like us. I might reply on the latest build thread later, anyway have a good one.

So far I haven't had any luck with this. I'm actually tempted to send my unit back to HTC with the ota 1.5 cupcake on it and see what happens. I'm not sure if it was working when they sent it to me or not. It doeswork with the rc29 though.

I'm having the same issue, no compass apps seem to work, google sky maps doesn't work , the level app doesn't work, all are froze.
How can I fix it?

Genie News & Weather Widget Issue?

Anyone else having a problem with the genie widget today?
I can't get mine to load anything, and a message pops up:
"Sorry, unable to connect. Please try later."
I have to guess google accidentally changed something on their end that the widget is connecting to, that is failing, for retrieving the necessary data.
I am seeing the following in logcat:
Code:
D/Genie ( 835): Requesting data...
D/Genie ( 835): Request in-flight, ignoring.
D/Genie ( 835): [b]Making MASF Request to http://www.google.com/m/appreq - g:gne[/b]
/r: GenieRequest [no fake location] type: [15, 16] with ma
xAge: 21600000 at 4:16pm, June 16
D/Genie ( 835): Network status: CONNECTED
D/Genie ( 835): MASF cache miss
D/Genie ( 835): ctrl.requestData has finished.
D/Genie ( 835): RefreshService: Waiting for requestlatch to clear...
D/Genie ( 835): MASF cache miss
D/Genie ( 835): [b]Request failed, and nothing in cache[/b].
I/Genie ( 835): Next data refresh scheduled for: 10:16pm, June 16 (basetime w
as 4:16pm, June 16)
D/Genie ( 835): [b]Request failed at, 4:16pm, June 16 next auto-refresh time =21[/b]
Just want to see if I am the only one...

Nope, your not. I'm having the same problem. It was fine yesterday. Today it doesn't work.
I also found a post here where some Nexus One users reported the same (including one who is unrooted).
On another forum somewhere withe an Evo is having the same problem.
All of this only today. So it much be a Google thing.

What version are you guys using? Mine works perfectly fine...

I may be running an older version, as I keep carrying the one I have forward from ROM to ROM, based on customizations I'm too lazy to re-do.
Mine shows as 1.1.7 RC6.

Nope just checked mine after I saw ur post. Did a refresh and it works perfectly
-------------------------------------
Sent via the XDA Tapatalk App

JsChiSurf said:
I may be running an older version, as I keep carrying the one I have forward from ROM to ROM, based on customizations I'm too lazy to re-do.
Mine shows as 1.1.7 RC6.
Click to expand...
Click to collapse
Mine is 1.2.02 RC2. And shes purrin along...

gomorrah said:
Mine is 1.2.02 RC2. And shes purrin along...
Click to expand...
Click to collapse
Do you have a link to that version anywhere? All the ones I keep finding are the same version as mine, which, from what I'm reading is probably the cause of the problem.
Thanks.

JsChiSurf said:
Do you have a link to that version anywhere? All the ones I keep finding are the same version as mine, which, from what I'm reading is probably the cause of the problem.
Thanks.
Click to expand...
Click to collapse
Gimmie a sec. I only have my themed one, it might be the same one that comes in DD. Ill check.
Try this one and let me know. I didnt check, Im just assuming...

Posted one in above link^^^^
EDIT- Verified its the newer version.

gomorrah said:
Posted one in above link^^^^
EDIT- Verified its the newer version.
Click to expand...
Click to collapse
Dang. New version, same result! I appreciate you taking the time to post it.
Now I'm wondering if the issue is based on location, or if you guys have a cache that you are running off of, where my cache is blank, and therefore failing.
Do you see anything in your logcat regarding successful update, or, how old our your latest news updates?

im using DC 2.0.9.1 and the genie widget is working just fine

Yea, this is not ROM dependent / specific. A quick google search shows it's popping up everywhere. I suspect when your cache expires, everyone's will bork too, unless a remote fix is done before this happens.
The same version on my wife's hero was working when I got home from the office, and has now stopped as well.
If someone who has it still working can remove and re-add, while watching their logcat, to see what messages appear regarding success / fail on the call to google, it would help immensely.

ill give it a shot
heres what i got
D/Genie ( 856): Location Listener has stopped listening for updates.
D/LocationManager( 856): removeUpdates: listener = com.google.android.apps.geni
[email protected]
D/LocationManagerService( 433): Released wakelock
D/NetworkLocationProvider( 433): removeListener(): apps.genie.geniewidget
D/NetworkLocationProvider( 433): setMinTime: 300000
D/Genie ( 856): Got updated location: 33.21527777777778, -97.14527777777778 +
/-1000.0
D/Genie ( 856): Requesting data...
D/Genie ( 856): Making MASF Request to http://www.google.com/m/appreq - g:gne
/r: GenieRequest 33.21527777777778,-97.14527777777778[no fake location] type: [1
5, 16] with maxAge: 0 at 8:56pm, June 16
D/Genie ( 856): Network status: CONNECTED
D/Genie ( 856): Cached entry too old
D/Genie ( 856): MASF cache miss
D/dalvikvm( 856): GC freed 4962 objects / 442080 bytes in 196ms
D/Genie ( 856): Request failed, falling back to cached data.
D/Genie ( 856): Got response: GeniePayload: isCached: true payload: 41 and up
dated model: READY: showing news 0 of 40 weather=Partly Cloudy at, 8:56pm, June
16 with timestamp: 3:33am, June 16 next auto-refresh time = 0
D/Genie ( 856): Refresh Complete, notifying success.
D/Genie ( 856): Refreshing widget.
D/Genie ( 856): RefreshService: Done, fetching news and weather icons.
D/Genie ( 856): NewsImageCache: Cache: 100 items in index, and 101 files on d
Click to expand...
Click to collapse

Thanks. Yep, exactly as expected.
Code:
[b]D/Genie ( 856): Request failed, falling back to cached data.[/b]

here's mine, left it complete just in case (had to zip to upload here)
edit: mine does not fail, and I show version 1.1.7 rc6

no problem

danaff37 said:
here's mine, left it complete just in case (had to zip to upload here)
Click to expand...
Click to collapse
Yours appears to be working. Do you know your version number?

haha I edited my post the exact minute you asked. lol

danaff37 said:
haha I edited my post the exact minute you asked. lol
Click to expand...
Click to collapse
I see it now . Shoot, that's the same version I was running originally. This makes me think it must be a location issue, or maybe you are pulling the data from a different server based on location.
Guess those it's not working for have to wait it out, as I'm not sure how we could fix it based on the variability and the fact that the same version is working for some and not for others...

if it is location based, in tampa, fl area here for comparison sakes

Open Source CM10.1 for Dell Streak 7 continuation

First you need to have giveen's original port installed: http://goo.im/devs/giveen/jellystreak (via the old thread: http://forum.xda-developers.com/showthread.php?t=2130081). The most important thing this does is installing the TWRP "recovery" bootmenu thingy. You can use it when powering on/restarting the dell streak 7 and then keeping power+volup pressed and then choosing "install update from sdcard" or so.
With AOKP there is one install image that wipes /system and an ota update. I have not tested the ota update.
Download for the AOKP 4.2 build for the Dell Streak 7: http://w3studi.informatik.uni-stuttgart.de/~haagch/aokp/
The non-ota update wipes /system. So you have to reinstall gapps every time too, preferably before rebooting (android deletes settings for apps that are not installed I think).
The "official" gapps package uses neon instructions that don't work on tegra2. You'll see the keyboard, tts, etc. crashing all the time. "tonyp" has created a gapps package that uses "old" libraries that work without neon instructions. So you should use this instead of the official gapps:
Download for non-neon gapps: http://goo.im/devs/tonyp/non-neon-gapps
Gesture typing on the keyboard doesn't seem to work for me, but tts works and it doesn't seem to be crashing.
Known issues for me:
[*]sensors don't work: rotation, accelerometer, gps (I think), magnet field (Sensor driver is sensors.p3.so for now, maybe later giveen gets open source drivers to work)
headphone jack doesn't mute/transfer for some headsets like ones with built in microphones
bluetooth keyboard
Performance problems. Especially when the ram gets full. You can use a ram manager like https://play.google.com/store/apps/details?id=com.jrummy.apps.memory.manager with the Aggressive or Extreme preset to make that problem go away with the cost of background apps being killed very quickly.
Here is the repository: https://github.com/ChristophHaag/android_device_dell_streak7
And here is how to build it on Archlinux:
AOKP: https://gist.github.com/ChristophHaag/6334554
Cyanogenmod: https://gist.github.com/ChristophHaag/6078249
I'm new to android but maybe some other people know something, so I post whatever I come about. Maybe someone else wants to get started too and finds this helpful.
If you want to engage in bug finding and fixing yourself:
Remote debugging c works like this:
On the android device you do
Code:
gdbserver --remote-debug :5039 --attach 1
Which will attach gdbserver to the process with pid 1 and listen on port 5039 on all interfaces.
For a gui debugger I tried nemiver:
For $ANDROID I use the path where the cyanogenmod was checked out.
Code:
nemiver --remote=<STREAK7-IP>:5039 --gdb-binary=$ANDROID/android/system/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-gdb --solib-prefix=$ANDROID/android/system/out/target/product/streak7/symbols/ $ANDROID/android/system/out/target/product/streak7/symbols/init
And in edit-preferences for sources I added some paths like symbols/, symbols/system/lib and the android/system directory.
There's also a statically compiled gdb that you can use over ssh or so: http://dan.drown.org/android/howto/gdb.html
Obsolete first look into the CyanogenMod adb bug:
I think the problem is in line 1068 in init.c
Code:
if (!action_queue_empty() || cur_action)
timeout = 0;
each time I looked when it comes there the cur_action->name was "property:sys.usb.config=none".
Maybe it is connected with the adb issue. When I googled for the
Code:
E/UsbDebuggingManager( 367): Communication error:
E/UsbDebuggingManager( 367): java.io.IOException: No such file or directory
E/UsbDebuggingManager( 367): at android.net.LocalSocketImpl.connectLocal(Native Method)
E/UsbDebuggingManager( 367): at android.net.LocalSocketImpl.connect(LocalSocketImpl.java:238)
E/UsbDebuggingManager( 367): at android.net.LocalSocket.connect(LocalSocket.java:108)
E/UsbDebuggingManager( 367): at com.android.server.usb.UsbDebuggingManager.listenToSocket(UsbDebuggingManager.java:79)
E/UsbDebuggingManager( 367): at com.android.server.usb.UsbDebuggingManager.run(UsbDebuggingManager.java:115)
E/UsbDebuggingManager( 367): at java.lang.Thread.run(Thread.java:856)
issue I found surprisingly many people having issues with this, but few answers.
But I also found e.g. this: https://gist.github.com/steven676/5...c-remove-obsolete-ro.debuggable-1-trigg.patch
so the problem may be in https://github.com/ChristophHaag/an...lob/master/prebuilts/root/init.streak7.usb.rc
but I didn't have time to really read documentation to that.
I think this file complements $ANDROID/system/core/rootdir/init.usb.rc
I'll either play around with that or I'll add debug output in android.net.LocalSocketImpl.connect(LocalSocketImpl.java:238)
Code:
connectLocal(fd, address.getName(), address.getNamespace().getId());
Then I would at least know what it's trying to do and it would get easier.
Many of the results I saw from googling mentioned that it might have to do with netd.
On the streak 7 I get this:
Code:
cat /dev/socket/netd
cat: can't open '/dev/socket/netd': No such device or address
I'm not sure if this is how it should behave...
An observation is that adbd run from a command line seems to start without an issue and listens on a port specified with
Code:
setprop service.adb.tcp.port 5555
but the access over adb connect <STREAK7-IP> does only say "unauthorized". And "start adbd" does nothing. None of the programs seem to have --help or -h, so I have to look closer into whether they can be started directly.
I'll change "[ro.adb.secure]: [1]" in /default.prop to 0 and see whether that does anything.
In the other thread from giveen I said that I don't see the log spam. This was with debugging in the developer settings disabled. When I enable it, the logspam starts. But whether it is enabled or not, init still eats 100% cpu. The trouble with the debugging is that each time it is enabled and I want to disable it, the streak 7 immediately reboots.
Now that I had logcat via ssh running I caught this when the reboot happened:
Code:
W/dalvikvm( 367): threadid=50: thread exiting with uncaught exception (group=0x40b0e930)
E/AndroidRuntime( 367): *** FATAL EXCEPTION IN SYSTEM PROCESS: UsbDebuggingHandler
E/AndroidRuntime( 367): java.lang.NullPointerException
E/AndroidRuntime( 367): at com.android.server.usb.UsbDebuggingManager.closeSocket(UsbDebuggingManager.java:125)
E/AndroidRuntime( 367): at com.android.server.usb.UsbDebuggingManager.access$200(UsbDebuggingManager.java:46)
E/AndroidRuntime( 367): at com.android.server.usb.UsbDebuggingManager$UsbDebuggingHandler.handleMessage(UsbDebuggingManager.java:177)
E/AndroidRuntime( 367): at android.os.Handler.dispatchMessage(Handler.java:99)
E/AndroidRuntime( 367): at android.os.Looper.loop(Looper.java:137)
E/AndroidRuntime( 367): at android.os.HandlerThread.run(HandlerThread.java:60)
Looks bad.
For looking at the android code I just use grep and ls with globbing for the c and config files and for the java part I imported it in eclipse via this method: http://source.android.com/source/using-eclipse.html
This is a build I haven't tested yet: http://w3studi.informatik.uni-stuttgart.de/~haagch/cm-10.1-20130820-UNOFFICIAL-streak7.zip
This is giveen's original nvflash that I am not sure I am allowed to put there as giveen has not put any license information in there: http://w3studi.informatik.uni-stuttgart.de/~haagch/JB_Beta2.1.zip But then it's all apache code and there are no notices in reagards to the apache license or changed files anyway. If not, you can just tell me and I'll remove it.
------------------------------------------------
So the call to connectLocal() that throws the exception has as parameters
fd: FileDescriptor[263]
address namespace: RESERVED with address name space id: 1 and address name: adbd
That doesn't help me much yet, but there are frequent calls with FileDescriptor[263] and namespace RESERVED, id 1, name rild (radio service) that don't throw an exception.
So it's a "valid" file descriptor... But I think the problem is still that adbd is not started by init...
The whole UsbDebuggingManager.run method is
Code:
public void run() {
while (mAdbEnabled) {
try {
listenToSocket();
} catch (Exception e) {
/* Don't loop too fast if adbd dies, before init restarts it */
SystemClock.sleep(1000);
}
}
}
where listeToSocket() is ultimately throwing the exception.
I have also read a bit about how adbd is supposed to work. Apparently in android 4.2.2 they introduced rsa encryption. It looks very similar to ssh. You have your authorized public keys on the device in /data/misc/adb/adb_keys (like ~/ssh/authorized_keys) and on your computer you have your public key in ~/.android/adbkey.pub
So I put my ~/.android/adbkey.pub in /data/misc/adb/adb_keys on the streak 7 and started adbd from the command line on the device. And indeed, when I connect with "adb connect <STREAK7-IP>" I get "<STREAK7-IP>:5555 device product:cm_streak7 model:Streak_7 device:streak7" with "adb devices -l" and adb shell works. It's a bit unrelated, but this applies: https://code.google.com/p/android/issues/detail?id=48126
But the actually important part, the "start adbd" still doesn't do anything.
It really must be somethin with /init.streak7.usb.rc. The stuff in /sys/class/android_usb/android0/ seem to be set all wrong...
------------------------------------------------
I'll just keep posting random things I discover that I find strange or interesting and if anyone knows anything about any of those, they can just chime in.
In /init.streak7.usb.rc there is the line
Code:
write /sys/class/android_usb/android0/iProduct $ro.product.model
"getprop ro.product.model" says "Streak 7" but /sys/class/android_usb/android0/iProduct apparently doesn't seem to be able to take a string with a space because "cat /sys/class/android_usb/android0/iProduct" returns "Streak". You can write directly to it with "cat "Streak 7" > /sys/class/android_usb/android0/iProduct" but it only saves up to the space. I don't think that's really a problem but strange anyway.
I have googled for another tegra 2 device and looked at its usb init rc: https://raw.github.com/CyanogenMod/android_device_samsung_p4-common/ics/init.p3.usb.rc
Adding a section with on property:sys.usb.config=adb did nothing and it seems I haven't been able to google what should be in /sys/class/android_usb/android0/idProduct for the streak 7.
I think I'll just look into how init on android works and how the triggers work. Then it shouldn't be too hard to figure out what exactly it is trying to do and why it is failing.
------------------------------------------------
I was trying to get my head around why "getprop sys.usb.config" would always return "none" and the system wouldn't respond to "setprop sys.usb.config adb,mtp" in any way. So I got to suspect that /init.streak7.usb.rc was not used at all. Then I compared the imports and found that /init.streak7.rc did use a relative path for /init.streak7.usb.rc while all the other init*.rc were using absolute paths.
So I'm not sure if it this is really the thing that fixed it, but it's the latest thing I tested and now init's 100% cpu and adb are fixed: https://github.com/ChristophHaag/an...mmit/eee0625e11cfafd510c3bada6ae67a133766c0f4
Edit: Wait, it happened again. Maybe not. :/
Hm, no, definitely not it. Can't even reproduce it. It worked after adb sideload and wiping the cache and the dalvik cache.
At least it's clear now that init's 100% cpu usage and adb not working and the dalvik crash when disabling debugging are all the same issue.

Good luck. I'll give you a hint as a parting gift. The USB issue is not kernel related.
I really dont care to licenses anything so you are free to do with as you will. Personally, I will continue to develop in private and if there are kernel changes, as per the GPL, I will make those updates available.

[moved to hidden section in first post]

[moved to hidden section in first post]

[moved to hidden section in first post]

If you really want to help, let me know. I'll let you in on my secret.

giveen said:
If you really want to help, let me know. I'll let you in on my secret.
Click to expand...
Click to collapse
Do I want to help? Does this thread look like I don't?
As I've said I'm new to the android code so I'm not really sure what I'm doing yet.
After rebooting with debugging enabled and adb sideloading an image it works for some reason (until you disable debugging in the developer settings, then it loops on sys.usb.config=none again) but it's all clearly not like intended by /init.streak7.usb.rc. /sys/class/android_usb/android0/idVendor is 18d1 and android_usb/android0/idProduct is d002 which is set in init.usb.rc for on property:sys.usb.config=adb...? I just don't get it yet. The init readme says declaring an action or service twice is an error but this is from upstream, so adb is supposed to always be 18d1:d002?
So if you know something I don't I would obviously greatly appreciate it if you told us. In fact you can directly push to the repository now if you wish to do so.

ccxxx said:
Do I want to help? Does this thread look like I don't?
As I've said I'm new to the android code so I'm not really sure what I'm doing yet.
After rebooting with debugging enabled and adb sideloading an image it works for some reason (until you disable debugging in the developer settings, then it loops on sys.usb.config=none again) but it's all clearly not like intended by /init.streak7.usb.rc. /sys/class/android_usb/android0/idVendor is 18d1 and android_usb/android0/idProduct is d002 which is set in init.usb.rc for on property:sys.usb.config=adb...? I just don't get it yet. The init readme says declaring an action or service twice is an error but this is from upstream, so adb is supposed to always be 18d1:d002?
So if you know something I don't I would obviously greatly appreciate it if you told us. In fact you can directly push to the repository now if you wish to do so.
Click to expand...
Click to collapse
The problem is CM.
I switched to AOKP which is close to Google's AOSP, and the problem solved itself. Something in the way USBManager is programmed in CM screwed things.

I got around to download aokp today.
The build system is slightly different, but easy enough to set up. I first just did an "update" to it, but the adb/init problem persisted, acore kept crashing (but deleting data for the contacts app "solved" that).
So I decided to finally make a factory reset. Not really sure what happens there, but that didn't delete the apps in /system/apps I think so I just wiped everything except sdcard etc. with twrp and installed the image again. This time it works better it seems. adb seems ok for now, cpu usage is okay.
The 4.2.2. google apps for that are these: http://goo.im/gapps/gapps-jb-20130812-signed.zip
Now I'm not sure: Would a factory reset/complete reinstall have helped with cyanogenmod too?
aokp is missing a few features cyanogenmod has, most notably the performance settings where you can overclock and set up zram with the gui.
Keyboard still crashes. Not really surprising that illegal instruction hasn't changed.
There doesn't seem to be recent apps when long pressing the home button. Strange.
Not sure how much I like it yet and whether I'd rather use cyanogenmod.
Here it is: http://w3studi.informatik.uni-stuttgart.de/~haagch/aokp_streak7_unofficial_2013-08-23.zip
Thanks, giveen.

No problem. AOSP keyboard burns RAM like nothing else. If you switch to an 3rd party keyboard , you will no longer crash. This problem is common on a lot of low memory devices. ZRAM doesn't really work. I have a script that I want to test out that DJ_Steve had originally wrote. Also, I will send you the sensor files you need to modify to get them to work.

google has this keyboard in the play store https://play.google.com/store/apps/details?id=com.google.android.inputmethod.latin and I got it from http://dl.androidnext.de/com.google.android.inputmethod.latin.apk. Works ok, but has issues like you can't disable the "ducking" blocking of "offensive" words...
The sensors changes you commited work well. Rotation/acceleration/magnet/light seem to react normally.
It's almost usable now.
For people building it from source: If you get a weird error like "ERROR: couldn't find <type 'property'> in build.prop" and can't find anything useful with google... I deleted out/* and did a complete rebuild and then it worked.
Plugging in a headset still doesn't turn off speakers but it seems only like a minor issue since it seems to be detected just fine:
Code:
V/WiredAccessoryManager( 374): Headset UEVENT: {SUBSYSTEM=switch, SWITCH_STATE=1, DEVPATH=/devices/virtual/switch/h2w, SEQNUM=2006, ACTION=change, SWITCH_NAME=h2w}
V/WiredAccessoryManager( 374): newName=h2w newState=1 headsetState=1 prev headsetState=0
W/AudioPolicyManagerBase( 103): checkOutputsForDevice(): No output available for device 0004
V/WiredAccessoryManager( 374): device h2w connected
Google tts is crashing like the keyboard (
Code:
F/libc ( 6525): Fatal signal 4 (SIGILL) at 0x5dc80738 (code=1), thread 6525 (gle.android.tts)
) but pico tts seems to work, at least with english.
A Google search gave me this:
http://stackoverflow.com/questions/7102606/sigill-in-android-ndk-code/7104177#7104177
And further this might be worth looking into: http://forum.xda-developers.com/showthread.php?t=2186251
Not sure whether it's simply neon instructions or register usage of 16+ since I haven't looked that close into the build system yet. But probably ILL_ILLOPC means it's a neon instruction.

So sensors work now? I've been at that for months and I wasn't sure if I got it right. If I got it right, that was months of work there that I wasn't even sure was going to work.
Headphones and microphones need to be adjusted in mixer_paths.xml

Months of untested work that just works? Impossible! :good:
I haven't done a really thorough test, but they all seem to be doing something. https://play.google.com/store/apps/details?id=imoblife.androidsensorbox seems to have a little problem with the directions with the rotated screen though. But in general it all does something that seems related to what I do to the device.

The AKM8973. is a chip that is normally found on qualcomm devices. So I had to track down the right HAL and then modify to work with Tegra sword ices. It's a terrible hack/slash, modify and pray it works job. I had Just finished. Does the screen rotate?

giveen said:
The AKM8973. is a chip that is normally found on qualcomm devices. So I had to track down the right HAL and then modify to work with Tegra sword ices. It's a terrible hack/slash, modify and pray it works job. I had Just finished. Does the screen rotate?
Click to expand...
Click to collapse
Yes, the screen rotates. And even more impressively, it rotates correctly!

Good. Now i can focus my energy on the camera.

Hm, having difficulty with my compiles booting. Chris, if you compile and upload the zip, I can give you my goo.im information and you can push it as an auto-update. Don't forget to include your name in there somewhere for credit as well as you are now part of the team.

giveen said:
Hm, having difficulty with my compiles booting. Chris, if you compile and upload the zip, I can give you my goo.im information and you can push it as an auto-update.
Click to expand...
Click to collapse
I have edited my first post.
http://w3studi.informatik.uni-stuttgart.de/~haagch/aokp_streak7_unofficial_2013-08-25.zip
http://w3studi.informatik.uni-stuttgart.de/~haagch/aokp_streak7-ota-eng.c-builder.zip
giveen said:
Don't forget to include your name in there somewhere for credit as well as you are now part of the team.
Click to expand...
Click to collapse
Yea, maybe if I contribute something substantial instead of cosmetic changes.

OH yeah, bluetooth keyboard, I see that as one of your issues. I'll upload a bunch of idc files that should at least address that issue, not sure though.

Are you missing any commits? I noticed your update has sensor working but my build does not.

NFC Firmware for HTC Desire C ROMs with NFC Enabled

Hi everybody !
In the attachment you will find nfc.golfu.so which is the firmware for HTC Desire C with NFC (phone model PL01110). I get it from RUU_GOLF_U_ICS_40A_H3G_UK_1.45.771.3_Radio_10.11.98.09H_1.06.98.13M2_release_266089_signed.exe that you can find on the net.
I upload firmware here because I have spend 3 weeks to get it working with [STABLE][ROM][4.1.2][JZO54K] CyanogenMod10 | BUILD #3.
On this rom, we see the NFC option but it can not enable it and we get the error hw_get_module() failed with logcat and the option stick unchecked.
With the attachement to this post, NFC is working (at least with JZO54K CM10 build#3), see logcat :
I/NfcService( 477): Enabling NFC
D/NFCJNI ( 477): Start Initialization
I/dalvikvm( 315): Jit: resizing JitTable from 4096 to 8192
D/NFCJNI ( 477): NFC capabilities: HAL = 8150100, FW = a76d0c, HW = 620003, Model = 10, HCI = 1, Full_FW = 109, Rev = 12, FW Update Info = 0
D/NFCJNI ( 477): phLibNfc_SE_GetSecureElementList()
D/NFCJNI ( 477):
D/NFCJNI ( 477): > Number of Secure Element(s) : 1
D/NFCJNI ( 477): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef
D/NFCJNI ( 477): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING]
I/NFCJNI ( 477): NFC Initialized​
So what to do do with this nfc.golfu.so ?
Uncompress file nfc.golfu.zip and you will get nfc.golfu.so
Put the file (nfc.golfu.so) on /system/lib/hw/ on your phone.
chmod 644 /system/lib/hw/nfc.golfu.so
Then reboot your phone and now, you can check NFC option and you can use it (at least with phone having NFC AND rom having NFC enabled)

roms2000 said:
So what to do do with this nfc.golfu.so ?
Uncompress file nfc.golfu.zip and you will get nfc.golfu.so
Put the file (nfc.golfu.so) on /system/lib/hw/ on your phone.
chmod 644 /system/lib/hw/nfc.golfu.so
Then reboot your phone and now, you can check NFC option and you can use it (at least with phone having NFC AND rom having NFC enabled)
Click to expand...
Click to collapse
And the phone is not working, now. I tried to reboot, it's never completing the bootstrap. I can use the recovery console, I tried to fix permissions but it's always the same. How can I remove that file from recovery console?

fankool said:
And the phone is not working, now. I tried to reboot, it's never completing the bootstrap. I can use the recovery console, I tried to fix permissions but it's always the same. How can I remove that file from recovery console?
Click to expand...
Click to collapse
It doesn't work for me
Bootstrap? Is that stuck on boot animation?
If so:
You can reflash the current rom. That removes all the installed mods but not the apps or any sdcard data.
/*Worked for me, maybe not for you...*\

julian6457 said:
It doesn't work for me
Bootstrap? Is that stuck on boot animation?
If so:
You can reflash the current rom. That removes all the installed mods but not the apps or any sdcard data.
/*Worked for me, maybe not for you...*\
Click to expand...
Click to collapse
Yes, there's always the boot animation. But If I reflash the current rom I'll loose the data saved on phone and I have to reinstall the applications.

fankool said:
Yes, there's always the boot animation. But If I reflash the current rom I'll loose the data saved on phone and I have to reinstall the applications.
Click to expand...
Click to collapse
As I know flashing a new rom witout a /system wipe will not delete the applications.
You can also remove the micro SD (If you have one) there are multiple ways to cpoy the files to a pc from like micro>usb
Flasing roms only disable xposed modules and reinstall the stock apps.
Maybe a backup will come in handy the next time

julian6457 said:
As I know flashing a new rom witout a /system wipe will not delete the applications.
You can also remove the micro SD (If you have one) there are multiple ways to cpoy the files to a pc from like micro>usb
Flasing roms only disable xposed modules and reinstall the stock apps.
Maybe a backup will come in handy the next time
Click to expand...
Click to collapse
My recovery is not finishing backup for 4 months. Before it works perfectly.. so, I have only old bakcup (fbefore the last rom flashing).
I tried by adb to remove nfc.golfu.so from /system/lib/hw/ but the phone still stucks on boot, so I'll not try to copy file by memory card (it will not be useful).
I reflashed the rom without erasing anything and the phone was rebirth. Thank you!
A strange fast blinking on the screen is annoying me now, why? It's like the old crt monitor using 60Hz frequency. I restarted the phone but it's still blinking, from the white screen after switch on. Can anyone help me to understand what's happening?
---------- Post added at 11:31 AM ---------- Previous post was at 11:25 AM ----------
fankool said:
A strange fast blinking on the screen is annoying me now, why? It's like the old crt monitor using 60Hz frequency. I restarted the phone but it's still blinking, from the white screen after switch on. Can anyone help me to understand what's happening?
Click to expand...
Click to collapse
Replying to myself: I only disabled "developer options" (my phone is in italian language, I suppose this is the translation), restarted the phone and removed the battery and now works perfectly. But still I don't know why it was blinking.

Well roms2000,
thank you for your job (even if it's not working on my phone) if you are interested now I can continue the tests on my mobile phone to use NFC, I know how to quickly recover my phone (I also updated my cwm and now the backup works perfectly).
I'm wondering why it stucks (I disabled boot animation at start so I can't say exactly when it freezes) and what is the logfile I can read to understand what's happening (obviously my phone has NFC, is the O2 version).
I'm using NOPE kernel v2.6 850MHz (but at 800MHz) on miniCM v6 (a derivation of cm10). I just followed the instruction, I copied nfc.golfu.so in /system/lib/hw using x-plore and with the same application I changed the attributes to 644 (maybe, but it's difficult, I could set a wrong attributes, but in this case I think android simply ignores the library).
Also removing the file (by adb from recovery) the phone always stucks.

Sorry for long response, I did not check this post, so i couldn't received notifications.
@fankool : do you have the NFC version of HTC Desire C ? If not, you can't enable NFC, and the file won't do anything for you.
For NFC, I have simply take the module on the official rom to get it working, if your rom is base on android 4.1.2, it should work. Try to use logcat to see some message about error and NFC.
--- Edit :
I don't think MiniCM has NFC soft enabled : check on your phone : Settings / Wireless & Network (More...) / NFC
If you have a check box for NFC, rom embed NFC soft, else, it is not and I don't think firmware / module will do anything.

my desire c has NFC (it's an O2 desire c, and with stock rom and the revolution 4.0.4 it worked), but the option to enable NFC disappeared, also trying with prometheus or nope. I installed many different roms based on 4.1.1 (cm, minicm, miui..) but always NFC was not working. How can I use logcat?

Can you try this rom : JZO54K CM10 build#3, like I did ?
For logcat, it will not be useful if you do not have the option to enable NFC.

htc desire c nfc
roms2000 said:
Hi everybody !
In the attachment you will find nfc.golfu.so which is the firmware for HTC Desire C with NFC (phone model PL01110). I get it from RUU_GOLF_U_ICS_40A_H3G_UK_1.45.771.3_Radio_10.11.98.09H_1.06.98.13M2_release_266089_signed.exe that you can find on the net.
I upload firmware here because I have spend 3 weeks to get it working with [STABLE][ROM][4.1.2][JZO54K] CyanogenMod10 | BUILD #3.
On this rom, we see the NFC option but it can not enable it and we get the error hw_get_module() failed with logcat and the option stick unchecked.
With the attachement to this post, NFC is working (at least with JZO54K CM10 build#3), see logcat :
I/NfcService( 477): Enabling NFC
D/NFCJNI ( 477): Start Initialization
I/dalvikvm( 315): Jit: resizing JitTable from 4096 to 8192
D/NFCJNI ( 477): NFC capabilities: HAL = 8150100, FW = a76d0c, HW = 620003, Model = 10, HCI = 1, Full_FW = 109, Rev = 12, FW Update Info = 0
D/NFCJNI ( 477): phLibNfc_SE_GetSecureElementList()
D/NFCJNI ( 477):
D/NFCJNI ( 477): > Number of Secure Element(s) : 1
D/NFCJNI ( 477): phLibNfc_SE_GetSecureElementList(): SMX detected, handle=0xabcdef
D/NFCJNI ( 477): phLibNfc_SE_SetMode() returned 0x000d[NFCSTATUS_PENDING]
I/NFCJNI ( 477): NFC Initialized​
So what to do do with this nfc.golfu.so ?
Uncompress file nfc.golfu.zip and you will get nfc.golfu.so
Put the file (nfc.golfu.so) on /system/lib/hw/ on your phone.
chmod 644 /system/lib/hw/nfc.golfu.so
Then reboot your phone and now, you can check NFC option and you can use it (at least with phone having NFC AND rom having NFC enabled)
Click to expand...
Click to collapse
can i flash this zip file with stock rom

Stock rom should have it.
If you flash with stock I don't know if it will enable NFC.

roms2000 said:
Stock rom should have it.
If you flash with stock I don't know if it will enable NFC.
Click to expand...
Click to collapse
Well, this firmware enabled NFC on Cyanogenmod 11 - confirmed working by one of users, so thanks for this.

I've flashed Stock ROM and deodexed ROM, neither had NFC working (although it's meant to be) so it could be in boot if it works or not as my handset is 100% known to have NFC but my Bootloader is 1.31 and not 1.28
Sent from my B1-730HD using XDA Free mobile app

[DEVS-ONLY] SuperSU developer discussion

THIS THREAD IS FOR DEVELOPERS ONLY. IF YOU ARE NOT A DEVELOPER (or very tech-savvy and well-versed), MOST LIKELY YOU SHOULD NOT POST HERE.
By request, I am creating this thread for developer discussion. This is the place for developers to ask questions about how to handle/implement/embed SuperSU, discuss the operation of SuperSU, suggest improvements to compatibility, etc.
This thread hopefully reduces important developer related matters from being buried in the more user-oriented threads.
Please always include the version number of SuperSU you are referring to, even if it's the latest version right now. If applicable, also include information about phone and firmware you are testing with.

Chainfire said:
The stop-gap solution is to disable this caching completely, which is what the 000000deepsleep script does, which you can find mentioned or quoted in many posts around the forum. From SuperSU 2.66 onwards, that script is automatically installed on Samsung devices when systemless root is used.
Click to expand...
Click to collapse
Please forgive me for posting (in a cf-auto-root thread) and digging afterwards. I had thought I'd just dump the info and forget about it, but I couldn't stop digging...
...which led me to the quoted material.
Digging in the supersu 2.66 update-scriptbinary, I see that you're detecting "samsung" in the build fingerprint, and if true, doing a systemless install AND applying a deepsleep fix. This works for Galaxy S6 devices, but not for some other similar platform devices. In particular, the Note5 has THREE devices that need caching disabled in order for deep sleep to function. (0:0:0:3 as well as :2 and :1.)
My first question is: does the SGS6 even have a file named "/sys/class/scsi_disk/0:0:0:3/cache_type"? If not, just write to all three files and don't worry about it. The third write would fail on the SGS6 and all would be good. It'd be no worse of a work-around than already exists (and I think it's a bad work-around.)
If that file DOES exist in the SGS6, then something would have caching turned off that really shouldn't. Of course, existing or not, automatically tossing in this deepsleep patch for every single device that has "samsung" in the build fingerprint would seem likely break proper caching in some yet unknown samsung device. Perhaps the SGS7 will change things up so that :1 should be left cache flushable, and :2 would be the only one that should block cache flushing.
As well, it's also possible that Samsung will pull in the kernel fix to resolve this issue before they release Android M. (Okay, perhaps it'd be more likely for Samsung to open source touchwiz... but we can always have fantasies.)
My problem with the work-around is expressed above: it can break something in the future (and cause a support headache when some ONE exynos7420 device is fixed, but the rest aren't.) As well, it sets precedent of having platform specific hacks in the generic update.zip (but only allowing for a single platform and not in an easily expandable way.)
Obviously, it would be a maintenance nightmare to have different "00000deepsleep" files for every different device model. (if 'zerolte.*', SGS6. If 'nobellte.*', Note5, etc.)...
In keeping with what I tell other people, I feel I now have an obligation to suggest A Better Way. (a person shouldn't complain about something unless they can make a reasonable suggestion on how it'd be better.)
So, here's my slightly convoluted (but expandable) suggestion:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
Code:
echo PLATFORMSTARTUP='echo "temporary none" > /sys/class/scsi_disk/0:0:0:1/cache_type' >> /data/.supersu
(I'd have included both (or all three) needed lines for samsung deep sleep, but I forget how to include CR in a shell cmdline.. )
Then, the supersu installer script would just read PLATFORMSTARTUP and write it's contents to /su/su.d/00000platformstartup (and set perms.)
Given this type of thing, the existing 000000deepsleep hack would be removed. Then, individual devs could easily create simplistic "pre-installers" for supersu for specific platforms that need changes. Those "pre" installers would just write the needed PLATFORMSTARTUP lines to /data/.supersu...
... and then supersu.zip no longer needs platform specific hacks.
Some random XDA developer could then generate a simple "SGS6-supersu.zip" would only contain an edify script to mount /data and add/edit the .supersu file's PLATFORMSTARTUP variable to contain the two lines needed for deep sleep (and another dev could write a Note5 for the 3 lines needed on that platform... and so on..)
Take care
Gary

garyd9 said:
You currently use /data/.supersu to read certain variables that modify the supersu.zip installer script. Perhaps those "platform specific lines" could be added to that file, and the installer script would put them in place. So, I could do the following in a recovery root shell before installing supersu.zip:
...
Click to expand...
Click to collapse
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep. The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.

NZgeek said:
The only problem with that is that it requires users to have two brain cells to rub together. We've seen time and time again on these forums that you can't assume this is always the case.
I think that Chainfire is doing pretty much the right thing here. At worst, disabling write-back caching will make I/O a bit slower, but that's better than not having deep sleep.
Click to expand...
Click to collapse
The problems with the existing solution are:
1. It blindly alters the system kernel behavior for every single device samsung manufactures.
2. It only actually does any good for a single one of the dozens of devices from that sam manufacturer.
3. It completely ignores every OTHER device that might need a bit of help (and potentially does more harm than good for those devices.)
4. It encourages device developers (users on XDA) to download SuperSU.zip and re-package it to have device specific hacks in the .zip archive (creating a mess.)
Actually, I don't think I need to explain all the problems with the existing hack. I'd imagine (hope) that it was done as something quick to test out an idea, and was never intended to be left in place in it's current form.
NZgeek said:
The only suggestion I'd have is to add more devices (maybe up to 5), and to check for their existence before writing to them.
Click to expand...
Click to collapse
Which 5 devices? Who maintains that list? Who updates it for each firmware change that might require an update? Will there be a new "SuperSU.zip" package each time a firmware change on a device requires that one of those 5 be changed? Who deals with the support nightmare of saying "use SuperSU v a.bc for device X firmwawre Y" and "superSU v d.ef for device X firmware Z", etc?
My proposed solution takes all the device-specific stuff completely out of the SuperSU package. It changes it from a device-specific solution to be a more generic and expandable solution that requires LESS support from SuperSU and places the device specific burden outside.
Instead of encouraging device developers to repackage supersu to device specific packages, it encourages device developers to package something else alongside supersu that would work with the existing (and unaltered) supersu.zip (and would be future compatible.)
Take care
Gary

spiral777 said:
would there be a way to get kexec/ multirom working with systemless root?
and would flashing a modified boot image to a rom also effect the kexec hardboot partch of the kernel?
Click to expand...
Click to collapse
1- the current versions of systemless root make changes/additions to the kernel, but you're not "flashing a modified boot img", so kexec is not broken, since the kernel is in essence the same as before
2- yes it is possible for systemless root (tested with 2.65) to get it working on multirom, however some changes were needed; we're still debugging the problem to try to narrow down the issue, to get it to work with as little changes as possible
EDIT: I'll just mention the problems encountered in case @Chainfire wants to be aware of them
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
EDIT2: thanks @Captain_Throwback for the reminder
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
just FYI, but I'll check more thoroughly when I get a chance

@garyd9 @NZgeek
Some good points are raised. I am not going to go into them all individually.
There is one core point of disagreement though. While I do not think device-specific patches generally have a place in the SuperSU ZIP installer, the deep sleep issue affects so many million users it is too big to ignore. (By the way, as far as I know this issue affects all recent high-end Samsungs).
While I don't disagree with your ideal of custom pre/post installers, in reality most users will never discover the issue, and just blame SuperSU for suddenly bad battery life. This leads to many support emails, thread posts, bad rep, etc.
Contrast this to for example the LG G3 compatibility patch, which requires the user to indeed write a file to /data or use a pre-installer that does that, the device will simply not boot, which forces the user to either go back to stock, or search for and discover the fix.
Either way, you are right, the patch doesn't even work right for Note users. Thank you for pointing that out - nobody else ever did. I have come up with the following improved script. If for the moment, we put aside our differences regarding the inclusion of any device-specific fixes, what do you think of the following?
It will perform the cache_type change for any scsi_disk, but will skip the ones not set to write protected. This should catch the problem with devices that have a different disk layout, and prevent accidental reduced I/O speed for devices that are not affected.
Note that it is my understanding that the write protection mode cannot be reset without a flash chip power cycle, and as the protection is set by the bootloader long before our check, checking once at boot should suffice.
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done

Chainfire said:
I would be grateful if you gave that a shot on an affected Note/Edge+ and report back. It successfully sets the cache_type for :1 and :2 on my S6.
Click to expand...
Click to collapse
I won't be able to properly test this until at least tomorrow (Wed) evening... However, in the meantime, the following screenshots suggest that it'd also work on the Note5:
https://goo.gl/photos/61JWzoA5ir3PcDNr9
(This is with a custom kernel, however. I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Let me know when you'd like to debate on if SuperSU should fix (non-root related) bugs in only specific devices, all devices, no devices, or if it should just support a hook to allow third parties to fix both current and future/past devices. (Please don't get the wrong impression from that statement. SuperSU is your product, not mine... However you implement things is up to you.)

Please do let me know if I can be of further assistance to fix compatibility.
nkk71 said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
c) the setprop sukernel.mount 1 (in launch_daemonsu.sh) doesn't trigger the mount properly, workaround was to mount it in the launch_daemonsu.sh using "mount -t ext4 -o loop /data/su.img /su" instead of the setprop
Click to expand...
Click to collapse
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
d) the attempted remount read-only, will cause a bootloop; workaround: had to comment that out
Click to expand...
Click to collapse
Where is this?

Chainfire said:
Please do let me know if I can be of further assistance to fix compatibility.
Click to expand...
Click to collapse
Thank you, I will let you know once I've had a chance to properly debug further
I initially only wanted to get systemless root to work, which using the workarounds (even though not ideal), was proof it can be done
(at the time it was SuperSU v2.65)
Chainfire said:
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
No need to take double symlinks into account, only the real one is changed as follows:
the real one is renamed with a "-orig" extension, and a symlink is created to an imaginary normal file:
Code:
cd [B][COLOR="Blue"]/dev/block[/COLOR][/B]
ls -l
...
brw------- 1 root root 259, 24 Jan 12 18:18 mmcblk0p40
brw------- 1 root root 259, 25 Jan 12 18:18 mmcblk0p41
[B]lrwxrwxrwx 1 root root 67 Jan 12 18:19 mmcblk0p42 -> /realdata/media/0/multirom/roms/HTC_One_M8_GPe_Marshmallo1/boot.img[/B]
[B]brw------- 1 root root 259, 26 Jan 12 18:18 mmcblk0p42-orig[/B]
brw------- 1 root root 259, 27 Jan 12 18:18 mmcblk0p43
...
all other symlinks to the block device remain as is:
Code:
cd[B][COLOR="Blue"] /dev/block/platform/msm_sdcc.1/by-name[/COLOR][/B]
ls -l
...
lrwxrwxrwx 1 root root 21 Jan 12 18:18 adsp -> /dev/block/mmcblk0p16
lrwxrwxrwx 1 root root 20 Jan 12 18:18 board_info -> /dev/block/mmcblk0p3
[B]lrwxrwxrwx 1 root root 21 Jan 12 18:18 boot -> /dev/block/mmcblk0p42[/B]
lrwxrwxrwx 1 root root 21 Jan 12 18:18 cache -> /dev/block/mmcblk0p46
...
Chainfire said:
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Will check, thanks.
Chainfire said:
Any idea why?
I'm specifically using the setprop / init.rc way because mount -o loop doesn't work on many firmwares.
Click to expand...
Click to collapse
Not really, everything else in init.rc get's executed properly; (and obviously the in launch_daemonsu.sh as well)
Chainfire said:
Where is this?
Click to expand...
Click to collapse
at the beginning of launch_daemonsu.sh:
Code:
if [ ! -d "/su/bin" ]; then
# if we fstab'd system/vendor/oem to rw, remount them ro here
remount_ro /system
remount_ro /vendor
remount_ro /oem
^^ I commented all three of them out, which worked out fine.
MultiROM's secondary ROMs always have system mounted rw, and the above remount_ro will force an immediate reboot
I need to do further testing on these issues, as soon as I come up with something more concrete, I will report back.
EDIT: forgot to mention, can confirm this for the HTC One M7, M8 and M9

garyd9 said:
I'll post a query in the Note 5 section asking people who are running a stock kernel to run similar commands to post the output here: http://forum.xda-developers.com/showpost.php?p=64773152&postcount=138 - I'll relay the results.)
Click to expand...
Click to collapse
So, two replies. I've edited the results to just show the device and value of write_protect. The first one is a KNOX tripped device with completely stock firmware/kernel (no root):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 1
scsi_disk/0:0:0:2 1
scsi_disk/0:0:0:3 1
The second is from a stock device where KNOX has never been tripped (the results are expected, but nice for confirmation):
Code:
scsi_disk/0:0:0:0 0
scsi_disk/0:0:0:1 0
scsi_disk/0:0:0:2 0
scsi_disk/0:0:0:3 0
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)

garyd9 said:
So far, all indications are that the change suggested would work.
Can I have your permission to modify the superSU 2.66 archive to change the deepsleep script to use the script above and forward it to a couple people to validate? (Or, I can just wait until tomorrow night and do it on my own device.)
Click to expand...
Click to collapse
Knock yourself out. I'm not in a rush though. I don't expect to release another update for another few days at least.

Chainfire said:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
fi
done
Click to expand...
Click to collapse
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards

dr.ketan said:
Confirmed working for all cache_types 1,2 and 3 but sorry I have patched kernel myself to fix so I have tested reverse just to prevent kernel swap.
Code:
echo 'write back' > /sys/class/scsi_disk/$i/cache_type
and it was write back for all 3. Indeed four including cache_type 0.0.0.0 as well)
So if i had test with
Code:
echo 'temporary none' > /sys/class/scsi_disk/$i/cache_type
then 0000 also get cached right?
It shouldn't be problem right? Just references to this post last line.
Regards
Click to expand...
Click to collapse
I don't know, since you changed it up, and your statement is a bit confusing.
Try this:
Code:
for i in `ls /sys/class/scsi_disk/`; do
cat /sys/class/scsi_disk/$i/write_protect 2>/dev/null | grep 1 >/dev/null
if [ $? -eq 0 ]; then
echo Write protected: $i
else
echo Write enabled: $i
fi
done
Copy/paste the output.

No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.

dr.ketan said:
No problem. I will go to office in couple of hrs. Remove deep sleep fix from kernel and then test script as per said.
Click to expand...
Click to collapse
That's not needed, just run the other script I pasted above. It'll show what we need to know regardless of your kernel being patched or not.

[email protected]lelte:/ $ su
[email protected]:/ # ls -l /sys/class/scsi_disk/
lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:0 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:0/scsi_disk/0:0:0:0lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:1 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:1/scsi_disk/0:0:0:1lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:2 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:2/scsi_disk/0:0:0:2lrwxrwxrwx root root 2016-01-13 15:35 0:0:0:3 -> ../../devices/15570000.ufs/host0/target0:0:0/0:0:0:3/scsi_disk/0:0:0:[email protected]:/ # cat /sys/class/scsi_disk/*/write_protect
0
1
1
1
[email protected]:/ #

dr.ketan said:
...
Click to expand...
Click to collapse
Seems fine!

I had some time to check a few things, so please find below my findings / possibly solutions
Chainfire said:
a) line 1170: dd if=/dev/zero of=$BOOTIMAGE bs=4096
since MultiROM creates a symlink, the above command actually starts nulling out a "dummy boot.img" file, which basically continues on, untill all free space in internal storage (or external sdcard where applicable) is filled out
Click to expand...
Click to collapse
I guess the script can be modified to detect a link and then check if said link is still pointing to /dev/...
Do double symlinks need to be taking into account? i.e. what is a symlink, /dev/block/platform/.../boot, /dev/block/mmcblk0pX, both?
Click to expand...
Click to collapse
Fixed it by using the following code (perhaps the readlink -f is redundant, but it worked fine)
(at line 1199 of SuperSU 2.66 updater-binary):
Code:
if [ -b `readlink -f $BOOTIMAGE` ]; then
dd if=/dev/zero of=$BOOTIMAGE bs=4096
fi
Chainfire said:
b) when MultiROM-TWRP finishes installing SuperSU, the fake /data is still "busy" (some open file or something else keeping it busy), since it's busy, it can't be unmounted properly, and the real mount points don't get restored
at that point mrom injection will fail
using a lazy unmount helped alleviate that (as a workaround), but obviously not the best solution
Click to expand...
Click to collapse
Complete guesswork, but the backing file may need to be released for the loop device.
Click to expand...
Click to collapse
Turns out the loop device was in fact the problem; after umount /su, it still showed:
Code:
~ # [6n[B]losetup -a[/B]
losetup -a
/dev/block/loop0: 0 /data/su.img
so I just used/added (at line 1218 of SuperSU 2.66 updater-binary)
Code:
umount /su
[B]losetup -d /dev/block/loop0[/B]
I know it was on loop0 so I didnt need to account for anything else, but maybe using
Code:
LOOPDEVICE=`losetup -f`
or something similar, and continuing from there could be an option
Haven't tried checking on the other issues, but will report back when I have something on those

@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.

nkk71 said:
I had some time to check a few things, so please find below my findings / possibly solutions
Click to expand...
Click to collapse
Thanks for the update. I'll have a look at those commands. losetup -f is specifically not used because I have already encountered devices/recoveries where the built-in losetup does not support this flag. So just loop0 and loop1 are tried, on failure, too bad (guess that could use improvement, hehe). The same goes for the -b test for if, and the -f flag for readlink. While I have not specifically tested the block device test, I know the symlink test fails on some devices. So I need to do some testing.
This is why some things in the ZIP are done is such weird ways instead of just using standard command, they're all work-arounds for encounted recovery versions that didn't support command X or flag Y ...
garyd9 said:
@Chainfire, early results on the deep sleep script change are 100% positive for both the Note5 and the edge+ devices.
Click to expand...
Click to collapse
Good news, as expected.