yashsingh1/xdaforums huggingface dataset:
[Nexus 4 Original Android Development] ziddey:
Update time. Took a more straightforward approach this time, and adjusted code to simulate what would happen if it "naturally" detected an ID_A condition (host mode with charging -- 36.5kohm between pin4/5). Consequently, this should have fixed all prior issues. Should be able to unplug/replug devices at will and maintain an unpopulated (empty) hub without charging issues or requiring a reboot to regain usb functionality.

I've left /sys/kernel/debug/msm_otg/mode in place, but would advise not manipulating it except for debugging purposes. The mechanism for activating host mode is unchanged, and you will likely run into issues.

Now based on Franco's git as of 3/1 (after r102).

Also changed usb mount point from /storage/usbdisk to /storage/usbdisk0. Update vold.fstab accordingly. This also breaks the posted framework-res.apk. I'm about to update to the current nightly, so I'll post a new file shortly.

diff msm_otg.c msm_otg.orig

694,695c694
<	// simulating aca_enabled() since using ID_A for host mode -ziddey
<	if (aca_enabled() || test_bit(ID_A, &motg->inputs))
---
>	if (aca_enabled())
1102,1103c1101
<	// force fast charging in host mode -ziddey
<	/*if ((motg->chg_type == USB_ACA_DOCK_CHARGER ||
---
>	if ((motg->chg_type == USB_ACA_DOCK_CHARGER ||
1108c1106
<	mA = IDEV_ACA_CHG_LIMIT;*/
---
>	mA = IDEV_ACA_CHG_LIMIT;
1215,1216c1213
<	// simulating aca_enabled() since using ID_A for host mode -ziddey
<	if (aca_enabled() || test_bit(ID_A, &motg->inputs))
---
>	if (aca_enabled())
2115,2121c2112,2113
<	if (line_state) /* DP > VLGC or/and DM > VLGC */ {
<	// simulating ID_A to force usb host mode with charging -ziddey
<	//motg->chg_type = USB_PROPRIETARY_CHARGER;
<	pr_debug("***FORCING USB HOST MODE WITH CHARGING - SET ID_A***\n");
<	set_bit(ID_A, &motg->inputs);
<	motg->chg_type = USB_ACA_A_CHARGER;
<	}
---
>	if (line_state) /* DP > VLGC or/and DM > VLGC */
>	motg->chg_type = USB_PROPRIETARY_CHARGER;
2975d2966
<	// need BSV interrupt in A Host Mode to detect cable unplug -ziddey
2977,2978c2968,2969
<	/*if (otg->phy->state >= OTG_STATE_A_IDLE);
<	return;*/
---
>	if (otg->phy->state >= OTG_STATE_A_IDLE)
>	return;
2986,2992d2976
<
<	// hack to disable usb host mode (if enabled) -ziddey
<	if (test_and_clear_bit(ID_A, &motg->inputs)) {
<	pr_debug("***UNFORCING USB HOST MODE WITH CHARGING - CLEAR ID_A***\n");
<	motg->chg_type = USB_INVALID_CHARGER;
<	motg->chg_state = USB_CHG_STATE_UNDEFINED;
<	}
3314,3316c3298,3299
<	// enable /sys/kernel/debug/msm_otg/host (for debug purposes only. manipulation not recommended) -ziddey
<	if (motg->pdata->mode == USB_OTG /*&&
<	motg->pdata->otg_control == OTG_USER_CONTROL*/) {
---
>	if (motg->pdata->mode == USB_OTG &&
>	motg->pdata->otg_control == OTG_USER_CONTROL) {

2013.03.14 1648ET: otg-franco-boot-03141621.img should have fixed all issues involving unpopulated hubs, unplugged devices, host mode timeout, and charging. changed main mount point to /storage/usbdisk0 since that seems to be the new standard (update vold.fstab accordingly). based on Franco's git as of 3/12 (after r102)
[Nexus 4 Original Android Development] sga999:
Thanks, ziddey. I like it that this is based on Franco's r102. Your version now shows as #11. It was #80 before, so I want to make sure I'm getting the right version. Is this #11 the current one?

No one gave me a solution to my problem with trying your changes to framework-res.apk on the stock rom. I wonder if I'm unable to do this for a stock rom at all. I found this thread where someone wants to make "enhancements" to the stock rom on the Nexus 4.

http://xdaforums.com/showthread.php?t=2066784

Post 3 says:

"Also you will most likely need a rom that's deodexed which the stock rom is not."

Could this explain why I'm not able to use a modified framework-res.apk on the stock rom (I get bootloop, even with the file you gave me)? I've done lots of googling, and I don't see others saying you can't change the framework-res.apk on stock, but I'm probably just missing something.
[Nexus 4 Original Android Development] ziddey:
http://xdaforums.com/showthread.php?t=746446&page=3#22

Try simply copying storage_list.xml from your new apk to the original.

http://xdaforums.com/showthread.php?t=1806602#5

Or you could try copying the meta-inf folder and androidmanifest.xml from the original apk if you want to work in the other direction.
[Nexus 4 Original Android Development] sga999:
Thanks for the suggestions! I've tried the first one, and it did work for me. (Your comment states exactly what I did, i.e. copy storage_list.xml from new to original, but the post you referred to was talking about the opposite direction). I haven't tried your second suggestion yet.

For "fun", I decided to install a deodexed version of 4.2.2 from here:

http://xdaforums.com/showthread.php?t=2147281

[ROM][OTA][mako]Android 4.2.2 JDQ39: Rooted Busybox Deodexed/Odexed (2/13/13)

Also, I think I found a bug in Framework Flasher! See my post:

http://xdaforums.com/showthread.php?t=1432152&page=11#110

I have made 3 different update.zip files for framework-res.apk. Let's call them:

a. update-odex (from your first suggestion)

b. update-nofix (made by Framework Flasher without my bug fix)

c. update-bugfix (made by Framework Flasher with my bug fix)

Here are results of several tests!

1. Stock odexed 4.2.2 will only work with your update-odex (a).

2. Stock deodexed 4.2.2 will work with ALL three update.zip versions (a, b, c)!

I had really hoped that update-bugfix would have worked on the odexed rom, but no such luck. (Your second suggestion about meta-inf and androidmanifest.xml may be necessary here).

So now I'm tempted to just stay on the deodexed rom, since it is more "lenient". I know there may be a slight performance hit in running the deodexed version (sorry, I don't know that much about this, but I read somewhere that separating out the .odex helped when loading an app). But is there any other reason I shouldn't stick with the deodexed rom?

P.S. Back to the real topic here!! Your current version is working well for me. Thanks very much.
[Nexus 4 Original Android Development] sga999:
Okay, this is the last time I'll clutter up this thread with stuff about creating framework-res.apk properly.

I have made 2 changes to Framework Flasher. The first change was already mentioned in the prior post (it is about fixing the incorrect -o switch on the '7za x" command line...this makes temp-files get created properly). The second change is to the COPY line when preparing to create update.zip). I'm putting UN in front of signedframework-res.apk. This is the modified line.

COPY "%~dp0place-framework-res-here\UNsignedframework-res.apk" "%~dp0resources\struct\system\framework\framework-res.apk"

The only way this change works is that I'm NOT executing step 3 (signing) at all, I just do steps 1, 2, and 4. The resulting zip (or unsigned apk) works for both stock 4.2.2 odexed and deodexed roms. Please note that if you want to sign the apk (I haven't figured out why you should ever sign framework-res.apk), this change to the COPY line is not correct.

ziddey, I read lots of posts about copying the original AndroidManifest.xml, META-INF folder into the new apk (as you said in one suggestion). And lots about copying the new resources.arsc back into the original apk. I'm not sure....all I know is that these changes to Framework Flasher work well for me,

EDIT: Another bug fix for Framework Flasher. This line had forward slash before resources.arsc, but I've changed it to backslash. However, I'm not sure this line should even be in the runme.bat. It seems like it should be the user's responsibility to delete files from temp-files. But I'm not sure what the author's intent was.

DEL /Q %~dp0temp-files\resources.arsc
[Nexus 4 Original Android Development] ziddey:
2013.03.17 1548ET: otg-aio-20130317.zip All-in-one flashable zip that includes modified kernel/ramdisk, vold.fstab, and precompiled storage_list.xml for framework-res.apk (thanks arpruss for precompiled zip-for-android). Kernel unchanged from last release (Franco r102 base), but removed unrelated line previously added to default.prop in ramdisk
[Nexus 4 Original Android Development] baltac:
Just tested the zip file and it's working (tested with a 4Gb usb stick, mouse and keyboard), but the "Mount/Unmount USB Storage" is not present in my settings page.

Just a little thing and after I'll not bother you anymore, with my noob questions: I'm not skilled with android programming, so I didn't understand almost anything of the contents of this thread, so I didn't understand if I need to revert the usb in a "standard" state after the OTG. Apparently all works normal without touch anything (connecting the phone to PC, it works as mtp device with adb support), but I remember that when I was on LG Optimus Dual, that in the first release of his ICS Rom hasn't the Mass Storage mode, I used to change the usb mount state (I was needed it when I'm on my Mac Book), with this adb strings:

#disconnect and reconnect after every command

#put the device to mass_storage mode, with adb support
adb shell "setprop persist.sys.usb.config mass_storage,adb"

#after mass_storage before disconnecting, change the usb mode to one of following states

#put the device in MTP mode, with adb support
adb shell "setprop persist.sys.usb.config mtp,adb"

#put the device in only charge mode with adb support
adb shell "setprop persist.sys.usb.config adb"

I've tried this in nexus (not the mass_storage, to avoid any possible data loss), and obviously they works. The question is: there is (if needed) an analog string to switch in OTG mode? I've tried with otg, host, usb_host, usb_otg... but nothing happens...
[Nexus 4 Original Android Development] ziddey:
What rom are you using? Can you check if you have a framework-res.apk.1 now and if it's a different size than framework-res.apk? I just tested again on cm10.1 and it seems to work fine. Basically, it should be making a backup of your original framework-res.apk to framework-res.apk.1, and injecting the new storage_list.xml into your existing framework-res.apk.

No, none of what you mentioned is relevant at all. I'm imagining it's because the Optimus Dual has both internal storage and support for an sd card, which isn't visible in mtp mode, and therefore you need usb mass storage in order to have it be visible when connecting to a pc.
[Nexus 4 Original Android Development] Abu-7abash:
Re: [OTG] [17MAR13] [DIRTY HACKS] Externally Powered USB OTG (Seeking Devs)

So flashing this on ANY rom would get me OTG support? Regardless of what kernel I'm running ..etc?
[Nexus 4 Original Android Development] baltac:
@ziddey: Well, yes sir, it was the point on LG O2X. :)

I've the Stock 4.2.2 rom, rooted, odexed. In /system/framework/, I've only framework-res.apk... I should put the modded one from the zip manually?

EDIT.: I've Just took a look to the mod.sh code. Substantially it copy framework-res.apk in tmp/framework-res, replace the storage_list.xml inside the apk, backup the original one then put it back... I'll try to do it manually from adb and let's see what is went wrong...

EDIT2.: Ok. Executing manually all the commands it results to me that when try to do any write operation in /tmp/framework-res folder, despite the RW mount, I get the "Read-only file system" error, dunno why. After some try I modded the bash code to work directly in the /system/framework folder, and finally it works.:

cp /system/framework/framework-res.apk /system/framework/framework-res.apk.1
./zip -rf /system/framework/framework-res.apk res

EDIT3.: errata corrige. hauhauha! what a noob! I mounted as rw the /system folder but not the entire root (/). Sorry. The script works as is, but for me, not when installing from recovery. Maybe the problem is in CWM 6.0.2.7?
[Nexus 4 Original Android Development] ziddey:
Hmm, I'm using CWM 6.0.2.3. Would you willing to try manually executing the lines in adb in recovery?

I'm trying to determine how much I can squeeze out of the regulator that's currently supplying power for slimport. Currently, I'm able to force it on, but it's not able to power any of my usb devices-- either not enough voltage or current. It looks like it's only supposed to supply 4-50mA @ 3.05-3.3v. I'll be pretty thrilled if I can get it to power a microsd-usb adapter.
[Nexus 4 Original Android Development] SSMI:
Re: [OTG] [17MAR13] [DIRTY HACKS] Externally Powered USB OTG (Seeking Devs)

If you look through the OTG threads there is someone that pointed out a tiny circuit component that would up about the voltage you have to 5v. I'm sure it lowers the current but a microscope reader shouldn't need much. I'll try and look for the posts later and link them.
[Nexus 4 Original Android Development] baltac:
Done step by step: no errors... Buh!? Maybe I did something wrong the first time... There is a way to execute the whole CWM script in verbose mode?
[Nexus 4 Original Android Development] Cuzz1369:
Re: [OTG] [17MAR13] [DIRTY HACKS] Externally Powered USB OTG (Seeking Devs)

It flashes Franco 102 if i understand correctly.
[Nexus 4 Original Android Development] Abu-7abash:
Re: [OTG] [17MAR13] [DIRTY HACKS] Externally Powered USB OTG (Seeking Devs)

Yeah I understand but what I mean is, can I flash it on top of any setup (rom+kernel) or is it only working on specific setups? Also, do I need to do anything else so as to get it working besides flashing the zip through recovery?
[Nexus 4 Original Android Development] abnormalreply:
I'm not sure how stupid this sounds, but forgive me if it does: since the iPod has its own power source, would I be able to use it as USB storage with the proper wires? (30-pin to micro USB?)
[Nexus 4 Original Android Development] ziddey:
There really wouldn't be anything that would be output I'd imagine, but you could check /tmp/recovery.log. I don't know if it'd show anything at all though. Try CWM 6.0.2.3?

The kernel is irrelevant since it'll be replaced with a modified version of Franco's, which should support any 4.2.2 rom. The update includes necessary changes in the ramdisk, will create the appropriate vold.fstab, and *should* modify your existing framework-res.apk (while making a backup in the same directory as framework-res.apk.1). Baltac has reported that the last part did not work for him. I have tested it with cwm 6.0.2.3, but will investigate it in the future. If anything, the framework-res.apk modification isn't essential. It provides an easy way of unmounting your drive before removal.

It should be possible assuming it presents itself as a mass storage device, although the current method of OTG detection is based on the "type" of charger connected. So you would have to manually enable host mode by issuing the following command as root in terminal: echo host > /sys/kernel/debug/msm_otg/mode

It's been years since I've touched an iPod. I just realized that it doesn't automatically scan and index media on the usb drive, so if the iPod still isn't storing songs in a user friendly file/directory structure, it will be pretty hard to play what you want, unless you're okay with shuffling everything. Either way, you'd have to use a file manager (or possibly a third party music app) to browse the iPod for what to play. I'll try to look into this soon to see if there's a way to get Android to scan the drive automatically.
[Nexus 4 Original Android Development] yellowdie:
Hey Ziddey, thanks for all of your great work! I'm new to the N4, but you seem to be making great headway here. :)

Franco just updated his nightly to r135 last night and it's an awesome piece of work. I'm by no means asking for a "when" (I'm not an XDA noob!), but I'm curious what your update course is going to be. Originally (at least when I got my N4), you were based on his Milestone 1, but when M2 came out, you updated to his last nightly (r134). So are you thinking about sticking to his Milestones or update with his nightlies? If this was a democracy (which it's not, and we Devs are happy that way), my vote would be for nightlies! lol. Thanks again!

:):D:laugh::good:
[Nexus 4 Original Android Development] SetiroN:
Ziddey,

all the last releases only include framework/script changes right?

Am I right thinking that the actual kernel msm_otg.c code is still the same?
[Nexus 4 Original Android Development] sga999:
Ritchea, interesting about what your settings look like in various versions of XenonHD. I can't seem to find version 8 on the server http://goo.im/devs/XenonHD_ROM. Under mako, it only has version 9. Do you know where I can find version 8? Or can you put it somewhere for me?

Thanks.
[Nexus 4 Original Android Development] ziddey:
2013.05.15 0124ET: ziddey-otg-05150124.zip Attempt to detect actual proprietary chargers (Apple-compatible) and charge properly. Update base to Franco's #136.

Took me way too long to realize the switch case didn't break, and instead fell through to the default case, leading to the "work order" being canceled. Anyway, this build is aimed at bringing back compatibility with actual proprietary chargers. I don't have one to test with, but based off sga999's logs, I'm hoping that all such chargers will register a portsc of 80001805. It's a roundabout approach, but I don't have a better solution at the time. The sequence of events: charger detected, charger type detected as proprietary, force proprietary to aca_a (id_a) for host mode with charger, switch to host mode, detect portsc register of 80001805, clear id_a / set proprietary, switch off host mode, start charging.

If it still doesn't work with your proprietary charger, please report your portsc (# dmesg | grep portsc). Or if you're finding that your usb devices are no longer working, chances are it's registering the same portsc :(.
[Nexus 4 Original Android Development] ziddey:
I'm not all too interested in keeping up with each nightly. That's why I stuck with the first Milestone. Franco's git's milestone branch wasn't updated to reflect M2, so I went ahead with the current nightlies. Ideally, it'd be nice to use a kernel module that'd hijack/hook/wrap/what-have-you the associated msm_otg functions, since it might then be loadable on any kernel. But that's really quite over my head, and everything I've tried so far has led to an immediate kernel panic.

Yes. The 5/15 release (after your question) has an if-statement to check for a particular portsc register. I'm hoping it'll be able to restore compatibility for real proprietary chargers.
[Nexus 4 Original Android Development] sga999:
Okay! Charging works for one out of my two power banks. My newer one is working, and I didn't even have it when I first gave you logs a month or so ago. The older one was the one you based all of the 80001805 stuff on, so I have no idea what's wrong. I'll get a log soon.

UPDATE: Well, the portsc for this older one is 84001405. I'm sure the logs I gave you before were with this older one, and you said it had 80001805. I don't remember if I ever looked at the log to verify that. I can go back and look at what I gave you before. Oh well, that doesn't really matter much...the point is that this one is different, and I don't know if you want to support all the different ones we may tell you about.

EDIT: I just looked back at when I got the 2nd power bank, and it was Mar. 28. And I gave you logs on Mar. 30, so I guess I must have been using the newer one to give you the logs. So the newer one must be 80001805 and the older one is 84001405.
[Nexus 4 Original Android Development] ritchea:
Try this link to my Gdrive. If it doesn't work, let me know. MD5: 14cd6865f06ab26eb8a92f3eb5e52add. It appears that G drive has changed since last time I offered up a link.
[Nexus 4 Original Android Development] yellowdie:
Understandable. Have you ever reached out to Franco to see if he's interested in helping/working with you to make things smoother on your end? Who knows? Maybe it's a quick flip of a switch on his end to make things work better on yours. :) If you're interested, PM me and I'll give you his email (he doesn't take PMs).
[Nexus 4 Original Android Development] sga999:
Thanks very much....your Gdrive was fine. I appreciate your help!
[Nexus 4 Original Android Development] ziddey:
sga999 and anyone else interested: http://d-h.st/lZZ

It's just a test build to output some debugging info. Check dmesg for:

<7>[ 56.599334] *** chg_det = 0 ***

<7>[ 56.629272] *** portsc = 8c000804 ***

<7>[ 56.629272] *** line_state = 800 ***

<7>[ 56.629272] *** dm_vlgc = 0 ***

That's an example with a usb hub of mine. And a usb keyboard:

<7>[ 177.380889] *** chg_det = 1 ***

<7>[ 177.409271] *** vout ***

<7>[ 177.409301] *** portsc = 8c000404 ***

<7>[ 177.409332] *** line_state = 400 ***

<7>[ 177.409332] *** dm_vlgc = 400 ***

As well, please provide the first "portsc = " after the usb host comes online.

I'd do more testing on my end but I gotta run for now.

Thanks

edit: Specifically, I'm really only looking for the output for actual proprietary chargers. I can determine sdp/dcp/otg on my end.

This is just a boot.img. You can just do a fastboot boot boot-05151743.img instead of flash.
[Nexus 4 Original Android Development] sga999:
I copied your file to kernel_backups and used Franco's app to flash it and boot. That seems to work well.

I did a test with power from laptop first, not seeing your edit. It seems like edits ought to send us a notification so that we know they're there. On the other hand, maybe that would occur too often and cause too many emails.

Anyway, here's about 250 lines from dmesg from a test where a flash drive is my usb device, I plugged power into newer power bank, then usb cable into phone. It shows what your first example above shows. And then the portsc after that is 88001205. Hope this is what you're looking for.

I did not get a log of trying with the micro sd card, which is causing more problems (double plug) than the flash drive. Let me know if you need a log of that too.

I'm assuming you didn't put any code in to allow my older power bank to charge the phone. It had the other code I gave you last night (84001405). I tried it now, not knowing if you made any changes...it is still not working.
[Nexus 4 Original Android Development] ziddey:
No, it's just has extra debug output, and I'm only looking for the data for actual proprietary chargers.
[Nexus 4 Original Android Development] sga999:
So are you saying the log I gave you was not what you wanted? It was from one of my two power banks, the one with the code that you know about. I didn't know if you wanted a log of the code you did not know about also (84001405).
[Nexus 4 Original Android Development] ziddey:
That log is of you connecting your Kingston DataTraveler.
[Nexus 4 Original Android Development] sga999:
Sorry, I thought you wanted a device connected. I guess you're going to have to make it very clear when you ask for something...I may have done what you wanted the first time you asked, but when I re-read it, I thought you meant something else. So you just want the charger and the phone hooked up with a "standard charging/data cable"? And do you want it done for both of my power banks?
[Nexus 4 Original Android Development] sga999:
See if these are what you want.