yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] bmakk2055:
Does this work without external power now, with just a regular otg cable now?

Sent from my

Nexus 4

or my

Nexus 7

using Tapatalk HD
[Nexus 4 Original Android Development] sga999:
It looks like you did change it to get bytes 9-12 in that last cut rather than bytes 11-12. That's all I was referring to....I just meant you probably needed to pick up 4 bytes instead of 2.

You probably don't mind changing this script every time your rom changes (and thus the 0x0546 and 0x548 will change). But if you wanted to make it more automated, couldn't you find the 'internal' in your storage_list.xml similar to how you found it in the original? You could then put "something special" in your file for the internal (and the usb), like 0xfffe and 0xffff. Those values would obviously never legitmately follow the x08000001. Then you wouldn't have to worry about both values getting changed with one tr command, so no need for a compare. Then you could do the 2 tr's, using those new special values as input and the internal values for output. I know you know all this, but I'm just throwing it out. You might want a way to not have to code for the new values every time something changes.
[Nexus 4 Original Android Development] ziddey:
I gotta head out and won't be able to work on it again until tomorrow.. Here's a test build: ziddey-otg-05081744.zip

It should work under most scenarios, but there is an event where there's unexpected behavior.

tr "\x08\x00\x00\x01\x46\x05" "\x08\x00\x00\x01\x$internalb\x$internala" < res/xml/storage_list.xml > temp.xml

tr "\x08\x00\x00\x01\x48\x05" "\x08\x00\x00\x01\x$usbb\x$usba" < temp.xml > res/xml/storage_list.xml

Given $internala=04, $internalb=ff, $usba=5, $usbb=1,

The first command changes 08 00 00 01 46 05 to 08 00 00 01 ff 04 (GOOD). However, it seems to have the side effect of changing 08 00 00 01 48 05 to 08 00 00 01 48 04. I don't understand why this is happening, and even more bizarre is the behavior of the second command afterwards.

Even though 08 00 00 01 48 05 is now 08 00 00 01 48 04, the second command still works to change the 48 to 01. However, the 04 sticks, when it should have been changed to 05 (well, it was originally 05..). It's crazy since it shouldn't have even matched at all since the 05 is somehow 04.

Anyway, I doubt that anyone will actually see that scenario, so I'm curious to see if the rest of the patch works as it should.

Cheers.
[Nexus 4 Original Android Development] sga999:
Something wrong with the link to the new zip file???
[Nexus 4 Original Android Development] ziddey:
Looks like devhost went down. Skip that build anyway. I switched to using printf and dd instead of tr. I was supposed to head out half an hour ago, so I don't have time to really test it. Seems to work, despite some warnings that it spews out.

printf "\x$internalb" | dd of=res/xml/storage_list.xml bs=1 seek=412 count=1 conv=notrunc

printf "\x$internala" | dd of=res/xml/storage_list.xml bs=1 seek=413 count=1 conv=notrunc

printf "\x$usbb" | dd of=res/xml/storage_list.xml bs=1 seek=552 count=1 conv=notrunc

printf "\x$usba" | dd of=res/xml/storage_list.xml bs=1 seek=553 count=1 conv=notrunc

New build attached.
[Nexus 4 Original Android Development] sga999:
Yes, that seems to work well. And I think it's nicer that you're not searching for specific values in your storage_list.xml. Of course, the offsets (412, 552, etc.) into storage_list.xml are hard-coded, but that's probably never going to change.

I thought it would be nice to use words instead of bytes (fewer lines and no test for 255 needed), so I tried the code below. It worked except for the printf's. They do store 2 bytes in the right place for both internal and usb, but the values stored were wrong. Maybe you can fix the printf to work, but I can't seem to find the correct syntax.

internal=$(od -x storage_list.xml | cut -b 13-72 | tr '\n' ' ' | sed "s/ //g" | grep -o '00080100....' | head -1 | cut -b 9-12)

internal_dec=$(printf "%d" 0x$internal)

dist_dec=$(strings resources.arsc | sed '/^storage_internal/,/storage_usb$/!d' | wc -l)

dist_dec=`expr $dist_dec - 1`

usb_dec=`expr $internal_dec + $dist_dec`

usb=$(printf "%x" $usb_dec)

......these store 2 bytes in the right place (so count must be working), but the bytes are incorrect

printf "\x$internal" | dd of=temp.xml bs=1 seek=412 count=2 conv=notrunc

printf "\x$usb" | dd of=temp.xml bs=1 seek=552 count=2 conv=notrunc

It looks like you can put '&> /dev/null' on the end of the printf commands, and you will suppress those record in/out messages (just redirecting stdout with > wasn't enough; I had to add stderr with &). But maybe it's interesting to see the output.

EDIT: I forgot to mention your issue with the tr commands. That is SO strange. I tried it too and got exactly the same thing you did. I can't imagine such blatant bugs being in that code. I don't have any linux or unix system on a PC, but I'm sure it must work there. Isn't the code just ported over? I wonder if the busybox developer would want to know about this.
[Nexus 4 Original Android Development] ziddey:
I dealt with individual bytes because of lack of experience. I'm sure the code could be far streamlined / written more elegantly, but that's something to look at down the road.

As for tr not working as expected, I'm pretty puzzled, especially with regards to why the second command worked half-way. That said, it's generally said that it's extremely bad practice to incorporate variables in such manner, so I'm assuming that's the reason. That and it was also questionable if tr would be able to handle null values (\x00) properly.

As it stood, I first tried to use tr when I was writing the script on Ubuntu, and the tr binary didn't work as I'd hoped. I switched to using sed and it worked fine. But the opposite was true of the busybox applets, and so I switched to using tr again.

Either way, using dd seems far more appropriate and maintains sanity, as far as introducing variables, so... I'll look into script cleanup down the road, but for now, I'm more interested in finding if these hex edits are enough for proper functionality.
[Nexus 4 Original Android Development] davebuk:
Build "ziddey-otg-05081818.zip" has cured the FC in storage settings and USB sticks are now labelled as 'USB Storage' correctly when using stock firmware.

The only issue I have (and was the same with previous builds) is that after choosing the 'UNMOUNT' option, I get a notification, after I have removed the stick, of "USB storage removed. Insert new media"

I cannot clear this notification other than by re-starting the phone.

Getting 'app info' from the notification says its the 'System UI' that is driving the notification (which makes sense :) ) but not sure if that points to anything helpful?

Do I need to look at running 'Stick mount' or 'OTG helper' when running stock firmware?

Cheers.
[Nexus 4 Original Android Development] ziddey:
Unfortunately, from what I've read, that's a "bug" of the stock implementation. Aftermarket roms like CM allow you to dismiss that notification.
[Nexus 4 Original Android Development] davebuk:
No. Until someone can find a way to suck a bit more current from the Slimport chip and use a 3.3 to 5V converter, I think we are stuck with needing external power for a while yet!

Or someone may one day find out why the OTG part of the chip cannot supply the required 5V itself and run devices without external power.

---------- Post added at 09:18 AM ---------- Previous post was at 09:14 AM ----------

Force closing 'System UI' does clear that notification, but I'm not sure what effect that may have on the phone? It does change my wallpaper every time I do it :eek:

I have been putting off trying custom ROMs on my Nexus, but I may have to bite the bullet.

Thanks for your work so far ziddey.
[Nexus 4 Original Android Development] EDV11:
If you take the USB out without unmounting (I know is not the correct way) you will get an error, but you can swipe that away
[Nexus 4 Original Android Development] davebuk:
That is good to know. I guess as long as you are not actively using the USB stick, hopefully no corruption should occur on the phone or stick?
[Nexus 4 Original Android Development] ritchea:
The same has always happened for me even with "Unmount." It cannot swipe away with my rom (XenonXD). I haven't spent too much time trying to dismiss it as it's only superficial--it doesn't affect remount. Reboot will remove it, of course.
[Nexus 4 Original Android Development] RussianBear:
Anyone having issues with the storage "timing out" after the screen has been off for some time? Running a dash cam app in background with screen off, I'm losing the connection (led disappears).
[Nexus 4 Original Android Development] ziddey:
You said this wasn't an issue until recent builds? I just checked everything in msm_otg.c and don't believe anything has changed. Does it not time out if you keep the screen on?

What if you held a wakelock when USB is connected? I know it's not ideal, but since we need to supply external power anyway, it wouldn't make that much difference.

Other than that, host mode gets disabled if it detects a loss/change of power. If it's not making a good connection (say you go over a bump), maybe it loses connection for a split second, drops out of host mode, but then doesn't re-detect power because it happened too quickly, and so it stays out of host mode?

The dmesg log would help here, but I forgot to enable verbose usb messages it in the May releases (just did a make oldconfig with the r134 config). I'm going to recompile it with that flag enabled now.
[Nexus 4 Original Android Development] ziddey:
2013.05.09 1729ET: ziddey-otg-05091729.zip Didn't realize there were two octets responsible for the storage strings. Should actually work now. Re-enabled verbose usb debugging messages (dmesg).

md5sum ad5eb1d631df5b202cc0e9b7e034ed28

Thanks again, sga999.
[Nexus 4 Original Android Development] RussianBear:
I think the led going off is a software conflict. The cam app has an option to blink the led when it's working in the background mode. Thanks, ziddey!
[Nexus 4 Original Android Development] sga999:
ziddey, I played with the script a little more. None of this is very interesting, and I know you don't care about changing it right now. I'm sure there are many ways to do this. But I learned a little more and thought I'd tell you.

I think we were misinterpreting how the tr command works. It's not really searching for the entire string of hex characters you were looking for...it's translating each (aha, maybe that's why it's called translate!). So when you had the same value in the corresponding place in the input and the output, no translate would occur. But! When you had a difference between the input and output byte, ALL of the occurrences of that input got converted to the corresponding output. So when your tr command had \x46\x05 at the end of input and \ff\04 (with $internalb and $internala) at the end of output, that changed ALL 46's to ff's and ALL 05's to 04's. I don't think the nulls or the variables caused any problem in this case (you may be right that they may cause problems in some circumstances).

You added -q to the unzip of resources.arsc. Because I was trying this in a folder where I already had the file (which will not occur for you in your newly made folder), I got a prompt about replacing the file. So the -q is good enough to silence some output, but to get rid of this prompt, I added the "overwrite without prompting" option by changing the options to -oq . This isn't necessary unless someone is running your script outside of recovery, so I'm not suggesting that you change it.

The lines below seem to be working for me now (these 7 lines replace your 20 lines). Again, this is FYI, so ignore this if you want to. One interesting thing is that I had to change usb=$(printf "%x" $usb_dec) to usb=$(printf "%04x" $usb_dec). As an example, without the %04x, usb became 4e7, not 04e7. That messed up my subsequent printf because the cuts picked the wrong bytes!

internal=$(od -x storage_list.xml | cut -b 13-72 | tr '\n' ' ' | sed "s/ //g" | grep -o '00080100....' | head -1 | cut -b 9-12)

internal_dec=$(printf "%d" 0x$internal)

dist_dec=$(strings resources.arsc | sed '/^storage_internal/,/storage_usb$/!d' | wc -l)

usb_dec=`expr $internal_dec + $dist_dec - 1`

usb=$(printf "%04x" $usb_dec)

printf "\x$(echo $internal | cut -b 3-4)\x$(echo $internal | cut -b 1-2)" | dd of=res/xml/storage_list.xml bs=1 seek=412 count=2 conv=notrunc

printf "\x$(echo $usb | cut -b 3-4)\x$(echo $usb | cut -b 1-2)" | dd of=res/xml/storage_list.xml bs=1 seek=552 count=2 conv=notrunc

---------- Post added at 09:26 PM ---------- Previous post was at 09:08 PM ----------

Minor changes to those 8 lines...now 7 lines.
[Nexus 4 Original Android Development] wangtang:
I just tested your new patch around 1 and half hour.

I backup 2 roms via CWM that EOS and carbon rom.

Today patch is working, not bad.

i mean, both of roms can use otg fuction also no problem external battery charging.

but which rom should be support usb fast-charge option. just in my experience, i am not sure :)

one more thing! when i reboot Nexus4, i can't use external battery. if i want to using external battery, i have to connect usb otg (with external battery) or travel adapter first.

I don't know you fix external battery problem or not in 05/09 patch.

so, now i am on carbon rom with usb otg on my Nexus 4.

keep going ziddey! thank you
[Nexus 4 Original Android Development] ziddey:
Force fast charging (up to 1A) exists in Franco's kernel. Create an init.rc script to enable it:

echo 1 > /sys/kernel/fast_charge/force_fast_charge

As for proprietary chargers, functionality is broken on purpose. Please read the first post:

I will look to see if there's a good alternative trigger, or a way to differentiate between an actual proprietary charger and a usb device.
[Nexus 4 Original Android Development] wangtang:
i found one more problem.

I can't connect with computer via usb port. nexus 4 show me a error message "unfortunately, android.process.media~~~ has stop" something like this.

so i just back to normal ^^
[Nexus 4 Original Android Development] ziddey:
Please provide logs (dmesg and logcat in this case). Otherwise, I can't determine the issue. What rom? Does it always happen? Only after you've attached a usb drive?

It may be related to some of the other differing values in storage_list.xml, since that was really the only thing that changed recently. I can't reproduce it on my end.
[Nexus 4 Original Android Development] ziddey:
Here's a test build to try and fix support for actual proprietary chargers. I don't have any to test with, but going by sga999's dmesg from here, I'm hoping that they'll all register a portsc of 80001805. If that is the case (and there aren't any false positives), then we might have a "solution" for now.

ziddey-otg-05100327.zip a8249d92023c43f9224fc33e20d2e859
[Nexus 4 Original Android Development] Gia90:
I'm stuck on "Android id Upgrading: starting application".

I think it is happening after flashing "ziddey-otg-05061846.zip".

I've tried to flash the stock kernel but still no luck...

How can I undo all the modifications your zip did?

Thank you.

PS: I'm not sure this problem is caused by your zip, since my N4 sucessfully booted once.

I just want to try to remove every modification you did, to see if that was the problem and, if not, just reflash the ROM.
[Nexus 4 Original Android Development] mhanis:
Ziddey, i think my problem is the rom itself, for blank usb storage i use AOKP PUB rom. Just now i flash CM it works fine. No more blank usb storage
[Nexus 4 Original Android Development] RussianBear:
Regular aokp here and no issues.
[Nexus 4 Original Android Development] mhanis:
I'm using unofficial AOKP.

http://xdaforums.com/showthread.php?t=2146885
[Nexus 4 Original Android Development] ziddey:
What rom are you using? Sounds like a de-odexed one.. There's only two scenarios I can think of.. the first is that your rom has a custom ramdisk (in which case you'd be running into the same issue with Franco's kernel..). The second being the recent storage_list.xml patching.

As far as reverting modifications goes, the simplest approach is to simply reflash your rom. You should be able to just dirty-flash. No need to wipe data.

Otherwise, here is a list (reiteration of first two posts):

/system/build.prop - remove ro.usb.host=1 line from end of file

/system/etc/permissions/platform.xml - backup made as /system/etc/permissions/platform.xml.1

/system/etc/vold.fstab - delete file

/system/etc/permissions/android.hardware.usb.host.xml - delete file

/system/framework/framework-res.apk - backup made as /system/framework/framework-res.apk.1

kernel/ramdisk - reflash kernel or whole rom

That said, dalvik cache does not get wiped after flashing this patch, so I'm not sure why your phone was on that screen at all.

I wouldn't worry about the first 4 items on the list. They have zero chance of causing any problems. I'd first restore the framework-res (adb in recovery, unless you can drop a shell directly in recovery), and if that doesn't work, reflash the kernel you were using before (or whole rom).

If reverting your framework fixes it, I'd love to know what rom you're using / look at your storage_list.xml.
[Nexus 4 Original Android Development] ziddey:
Oh, I just understood what you meant (I thought you were saying the LED on your drive was turning off). Yeah, I noticed some anomalies in my LED behavior too (CM10.1), and from what I understand, Franco has made his own modifications for battery status while charging/charged, and it may be conflicting with other apps.

Also, another thing I just noticed. I think I remember reading it at some point, where someone said they had to plug the phone in twice for it to be recognized by the computer. I hadn't been able to reproduce it until now. Any chance force fast charge was enabled? That's the only scenario where I've run into that issue. I've taken a brief took at the code for that and am not sure why that happens. That said, I believe it's said that usb functionality should not be expected to work at all when enabling force fast charge.

Anyone care to try the new test build with an actual proprietary charger?
[Nexus 4 Original Android Development] sga999:
ziddey, I've had problems all along about when the USB storage is mounted. My problems have been with both the computer and the charger whether it's proprietary or not. But you and I had posted lots relating that topic (and other topics...one where I had a faulty cable), so I didn't really try to pursue it any more. I think I almost always have to plug it in twice, no matter what. But what I'm saying is not "scientific", and I don't have any real evidence to give you....I just decided it was acceptable.

I did try your test build late last night right after you posted it, but I didn't see any difference in behavior. I did not try to get any logs because it was late, and I've been busy today. So I'll try to get some information for you soon. I actually have two different power banks, and last night they behaved the same, i.e. had to unplug and replug. But I don't know if they both produce the 80001805 code that you mentioned. Is that what I would be looking for in the log in order to narrow down what you want to see? I had plenty of trouble getting you what you needed the last time, so I'd like to avoid that this time.
[Nexus 4 Original Android Development] RussianBear:
^^ try a different usb card reader, unless you're using an actual flash drive. One of mine turned out to have an issue.
[Nexus 4 Original Android Development] ziddey:
What sort of problems? A while ago, I left a usb stick connected overnight and it was still mounted and usable when I woke up. That said, usb storage specific problems would be out of scope of the actual otg mod. The host and devices are not allowed to go into suspended state, which should really rule out the "otg" side being at fault. The ROM side is pretty much a stock implementation (plus the permissions modifications).

That's the part I don't understand, and had never seen first hand until just now when I decided to enable force fast charge. All of the code changes in msm_otg.c occurs after the initial detection (we're piggybacking off charger type detection after all). So it should have no bearing on the initial detection. And from looking at the logs (with force fast charge enabled), the initial routine is flat out not occurring.

In the case of using a non-proprietary charger (say computer or wall adapter), it's like the modifications aren't even there. But if the issue of needing to double plug comes after using host mode, then it might be (although extremely far-fetched) because host mode charge rate is not limited to 500mA max:

/*if ((motg->chg_type == USB_ACA_DOCK_CHARGER ||
motg->chg_type == USB_ACA_A_CHARGER ||
motg->chg_type == USB_ACA_B_CHARGER ||
motg->chg_type == USB_ACA_C_CHARGER) &&
mA > IDEV_ACA_CHG_LIMIT)
mA = IDEV_ACA_CHG_LIMIT;*/

Your last log consisted of mostly error messages from not being able to detect the usb device. It was a constant stream as long as the proprietary charger was connected:

<7>[ 90.998046] msm_hsusb_host msm_hsusb_host: detected XactErr len 0/8

The two lines immediately before the errors are:

<7>[ 90.931512] portsc = 80001805
<6>[ 90.996551] usb 2-1: new full-speed USB device number 2 using msm_hsusb_host

So I'm hoping to be able to hijack it when it detects a portsc register of 80001805, switch the charger type to proprietary, and clear the host mode flag, sending it back to peripheral mode before it starts erroring. Of course, this means that it needs to switch to host mode initially, which is not ideal, but it'd be a simple fix.

When I get some more time, I'll try to create a proprietary charger and see if the D+ and D- linestates can be individually tested. That way, we could differentiate a true proprietary charger and a usb client from the get-go.

If you could just post the whole dmesg, along with the sequence of what you're doing, that'd be great.

For reference though, here's a slightly trimmed version of your past dmesg.