[USB OTG] [11DEC13] [PATCH] Externally Powered USB OTG - Nexus 4 Original Android Development

Externally Powered USB OTG - Nexus 4
This is an all-in-one patch to enable externally powered OTG (technically usb host mode) support. It's built off either the stock kernel or Franco's kernel sources, and should work with any ROM (that these kernels otherwise support). Refer to the second post for details on modifications and additions.
Again, power MUST be supplied externally, as there is no way for the phone to provide it.
Requirements:
Power MUST be supplied to both the USB device and phone. The easiest way would be by using an OTG Y-cable:
If using a traditional OTG cable, a USB Y-cable can be used:
Some powered USB hubs also send power up to the host and can be used directly with a regular OTG cable.
I am not endorsing any specific product or seller. Links are provided solely as examples, and are by no means definitive. As long as the phone and device both get 5V (charger, computer, etc.), and the data pins are connected, host mode will work (provided enough current can be supplied).
Installation:
Simply install the zip in recovery. Script will automatically install/patch necessary files. Must reinstall any time ROM is updated.
To uninstall, simply reflash your ROM. Data wipe is not necessary. If for some reason that's not an option, use the flashable unmod script to remove ROM-side modifications. Flash your kernel of choice afterwards (must flash "reset" kernel first if flashing an "anykernel").
Recovery:
(Optional)
For support in recovery, I've created a sort of "any-any" script. It replaces the recovery's kernel with the boot one. Therefore, by flashing this after the main patch, OTG will effectively be enabled in recovery (after a reboot). However, it is on the actual recovery itself to provide support for usb drives-- TWRP does. Otherwise, you'll have to manually mount any drives via linux console commands.
For your own safety/sanity, ensure the main patch works before flashing this. If recovery fails to boot after flashing, it can easily be replaced by using GooManager or similar. Worst case scenario, a new recovery can always be flashed via fastboot.
Downloads:
(Changelog at end of second post)
MAKE SURE TO DOWNLOAD THE RIGHT VERSION FOR YOUR ROM.
I don't keep track of all the different ROMs so it's on you guys to figure out which one is appropriate. The -CM builds have the two "CAF" commits that are now required for CM and its derivatives (unless they have specifically reverted the associated commits).
Franco-CM builds make use of a ramdisk mod script, which may have unpredictable results. Be ready in case it doesn't boot.
Current:
4.4.x: 2013.12.11 1604ET: [fk r199] [fk r199-CM]
4.4.x: 2013.12.06 1445ET: [aosp r7]
4.4: 2013.12.03 1522ET: [fk r197] [fk r197-CM]
4.4: 2013.12.01 1855ET: [aosp r6]
recoverymod.zip
Old:
4.3: 2013.10.27 1518ET Franco r193: [JWR] [JSS/JLS] [JWR-CM] [JSS/JLS-CM]
4.3: 2013.10.17 1957ET STOCK: [JWR] Stock kernel with OTG -- Only for stock rom
4.2: 2013.07.29 1101ET Franco r165: [JDQ]
ziddey-otg-unmod-20131002.zip
Bugs / Notes:
An OTG cable has the ID pin grounded out, which is used to trigger usb host mode. However, ID pin detection is broken in the Nexus 4 (although working for Slimport detection). Instead, we rely on detection of a "proprietary" charger (voltage on the data pins) in order to determine when to enable host mode.
Self-powered devices (e.g. digital cameras) don't send power to the phone. This will cause the device to not be detectable. Therefore, external power is still required.
Slimport cannot work concurrently with usb data due to hardware limitations (Slimport takes over the usb data pins).
USB drive will automatically mount at /storage/usbdisk0 (also accessible at /usbdisk and /mnt/usbdisk). Media scanning should occur automatically. Make sure to unmount before removal to avoid data loss.
Stock Android only supports FAT for storage. NTFS/exFAT/ext4 partitions may require the use of a third party app like StickMount (CM now supports these partitions natively!).
There appears to be a minor bug in the AOSP code that prevents available space from being reported in Settings->Storage->USB Storage. The screenshot is of CM10.1, which has this fixed
Current builds do not allow for host mode without charging. Use this as a workaround:
RussianBear said:
For those that want to stop usb charging, create a script modifying this to either 1 (disabled) or 0 (enabled). Works for me Not responsible for your phone(s) exploding.
echo 1 > /sys/module/pm8921_charger/parameters/disabled
echo 0 > /sys/module/pm8921_charger/parameters/disabled
Click to expand...
Click to collapse
Standard Disclaimer-- Flashing this patch is at your own risk, and carries no warranty or liability on my part. The assumption is that you will perform due diligence before flashing and make any necessary backups if required.
Screenshots:
Credits:
CaptainMuon, for proving that host mode is possible on the Nexus 4.
Franco, for his kernel, which this patch is based off.
garyd9, for his command to patch platform.xml.
Chainfire, for his usb host wisdom, and article on secondary storage write permissions.
arpruss, for his compiled zip-for-android
All you guys for testing!

---

Patch Overview:
Kernel with modified msm_otg.c -- This will REPLACE whatever kernel you currently have installed. If you flash a different kernel on top, you will obviously lose OTG capability. This contains the necessary workaround to enable usb host mode ("OTG").
Modified init.mako.rc/init.mako.usbdisk.rc -- Required for creating usb drive directories.
Precompiled modified storage_list.xml -- Allows unmounting usb drive in Settings->Storage. Hex offsets for storageDescription patched during flash.
Addition to build.prop -- Enables downloading apps from play store that require usb host mode support.
Addition to platform.xml -- Workaround to allow apps write access to usb drives
Addition to handheld_core_hardware.xml -- Activate android.hardware.usb.host.xml
android.hardware.usb.host.xml -- Enables Android API support for usb host mode.
fstab.mako (4.3) / vold.fstab (4.2) -- Required for automounting usb drive
Modules cifs.ko, ff-memless.ko, hid-dr.ko, hid-logitech.ko, and xpad.ko (/system/lib/modules). Manually insmod as needed or create an appropriate init.d script to load on boot. These are only required for certain gamepads. Refer here for more information.
Patch Details:
There seems to be an issue with detecting the state of the ID pin on the OTG cable, so we need to come up with an alternate way of determining when to switch to host mode. drivers/usb/otg/msm_otg.c (kernel) is responsible for detecting the charger type and setting host mode, among other tasks. I noticed that when connected to a powered OTG cable, the charge type becomes USB_PROPRIETARY_CHARGER (vs USB_DCP_CHARGER when connected to the wall, and USB_SDP_CHARGER to a computer). This will be the condition that we use to trigger host mode.
Standard OTG cables will have the ID pin shorted to ground. There are also usb accessory charger adapters (ACA) that provide different resistances between these pins to signal functionality (see http://en.wikipedia.org/wiki/USB_On-The-Go#OTG_Micro_Plugs). Support for accessory charger detection isn't enabled in the kernel originally, and doesn't seem to work properly anyway. However, one of the modes is essentially what we're trying to achieve (ID_A): "A charger and a B-device are attached. The OTG device is allowed to charge and enter host mode." So I've added code when USB_PROPRIETARY_CHARGER is detected to simulate the case of ID_A being detected. Following through the code for host mode, certain events are handled differently when ACA support is enabled (specifically, suspension of host mode). In these instances, we need to simulate ACA support since ID_A is technically dependent on it (run into issues with the usb controller getting stuck in a suspended state otherwise). Now we have host mode with charging working properly.
Finally, we need a method of detecting when the OTG cable is unplugged so the device can switch out of host mode. Fortunately, since power (vbus) detection does work, we can use that. Normally, changes in vbus state are ignored while in host mode, so we need to address that. From there, we simulate ACA detection for the case of no ID_A, which is just clearing the ID_A bit and charger. Afterwards, it'll automatically reset the usb state, ready to start all over again.
The dirty hacks to msm_otg.c are complete, and externally-powered OTG is functional.
Refer here for actual changes: https://github.com/ziddey/mako/commits/nightlies-4.3-JSS
No changes are needed to the kernel's .config. Do not enable Drivers->USB->OTG support (we get our support through "OTG support for Qualcomm on-chip USB controller" which is already enabled) or Support for ACA (does not work and most users don't have the proper adapter anyway).
Now we run into a problem with usb storage. Since there is no /system/etc/vold.fstab, usb drives get automatically mounted to /mnt/shell/emulated/0 (at least in CM10.1), which overloads the emulated sdcard, and causes major problems. So we create /system/etc/vold.fstab:
Code:
dev_mount usbdisk /storage/usbdisk0 auto /devices/platform/msm_hsusb_host/usb2
Update:
In 4.3, Google did away with vold.fstab, instead unifying mounting with fstab.mako (on the ramdisk). The replacement line would be:
Code:
/devices/platform/msm_hsusb_host/usb2 /storage/usbdisk0 auto defaults voldmanaged=usbdisk0:auto
Click to expand...
Click to collapse
Update:
In 4.4, mountpoint is set to auto instead of /storage/usbdisk0, and will be taken care of by vold / fuse daemon.
Click to expand...
Click to collapse
But /storage/usbdisk0 does not exist, so it will fail to mount. We will be using /init.mako.rc to create this directory and symlink associated legacy ones. This file resides in a ramdisk (which combines with the kernel to form boot.img), so we need to modify that instead of /init.mako.rc on the device itself (since it wouldn't be able to persist through a reboot). As well, we define the environmental variable SECONDARY_STORAGE. Below the analogous /storage/sdcard0 lines, add:
Code:
export SECONDARY_STORAGE /storage/usbdisk0
mkdir /storage/usbdisk0 0666 system system
symlink /storage/usbdisk0 /usbdisk
symlink /storage/usbdisk0 /mnt/usbdisk
Update:
In 4.4, usb disks must be further FUSE mounted. Rather than insert the script into init.mako.rc, it will now reside in init.mako.usbdisk.rc and be imported to init.mako.rc (strictly for ease/neatness and not standard convention):
Code:
# USB Storage -ziddey
on init
mkdir /mnt/media_rw/usbdisk0 0700 media_rw media_rw
mkdir /storage/usbdisk0 0700 root root
export SECONDARY_STORAGE /storage/usbdisk0
# Support legacy paths
symlink /storage/usbdisk0 /usbdisk
symlink /storage/usbdisk0 /mnt/usbdisk
service fuse_usbdisk0 /system/bin/sdcard -u 1023 -g 1023 -d /mnt/media_rw/usbdisk0 /storage/usbdisk0
class late_start
disabled
Click to expand...
Click to collapse
In order to enable Settings->Storage->USB Storage, res/xml/storage_list.xml in /system/framework/framework-res.apk needs to be modified. We should be able to simply inject an encoded version of our modified storage_list.xml. I'm not sure if it's possible to simply encode a single file, so I decompiled framework-res.apk in order to make the following addition to res/xml/storage_list.xml (inside StorageList):
Code:
<storage android:mountPoint="/storage/usbdisk0"
android:storageDescription="@string/storage_usb"
android:primary="false"
android:removable="true" />
After recompiling, we should now be able to extract our newly encoded storage_list.xml for use with any ROM's framework-res.apk.
To allow downloading apps from the market that require usb host support, we need to add the following to /system/build.prop:
Code:
ro.usb.host=1
To enable android api support for usb host, we need to create /system/etc/permissions/android.hardware.usb.host.xml with the following:
Code:
<?xml version="1.0" encoding="utf-8"?>
<permissions>
<feature name="android.hardware.usb.host" />
</permissions>
Now to "activate" this file, we add to /system/etc/permissions/handheld_core_hardware.xml:
Code:
<feature name="android.hardware.usb.host" />
Google assigned a different permission group for secondary storage devices (e.g. usb drives), media_rw, for which user apps cannot have write access (Chainfire has a good article on the issue here). We need to modify /system/etc/permissions/platform.xml to allow write access. Add the line in red ("officially" used by Samsung):
Code:
<permission name="android.permission.WRITE_EXTERNAL_STORAGE" >
[color=red]<group gid="media_rw" />[/color]
<group gid="sdcard_rw" />
</permission>
That's it! Externally powered usb host mode should be fully functional.
For full disclosure, these are the changes to the kernel config vs stock (really just NTFS and modules):
Code:
echo "CONFIG_INPUT_JOYSTICK=y" >> .config
echo "CONFIG_JOYSTICK_XPAD=m" >> .config
echo "CONFIG_JOYSTICK_XPAD_FF=y" >> .config
echo "CONFIG_JOYSTICK_XPAD_LEDS=y" >> .config
echo "CONFIG_INPUT_FF_MEMLESS=m" >> .config
echo "CONFIG_HID_LOGITECH=m" >> .config
echo "CONFIG_LOGITECH_FF=y" >> .config
echo "CONFIG_LOGIRUMBLEPAD2_FF=y" >> .config
echo "CONFIG_LOGIG940_FF=y" >> .config
echo "CONFIG_LOGIWHEELS_FF=y" >> .config
echo "CONFIG_HID_DRAGONRISE=m" >> .config
echo "CONFIG_DRAGONRISE_FF=y" >> .config
echo "CONFIG_CIFS=m" >> .config
echo "CONFIG_NTFS_FS=y" >> .config
# echo "CONFIG_USB_DEBUG=y" >> .config
sed 's/\(CONFIG_USB_STORAGE_DEBUG\)=y/# \1 is not set/' -i .config
Changelog:
4.4: 2013.12.01 0349ET: [fk r196] [fk r196-CM] [aosp r5] aosp includes gamepad kernel modules.
4.4: 2013.11.29 0219ET: [fk r195] [fk r195-CM] CM build attempts to patch Franco ramdisk mods on the fly, so be prepared if things go south.
4.4: 2013.11.21 1922ET: [fk r194] [aosp r2] Update to 4.4 configuration for mounting usbdisk.
4.3: 2013.10.22 2201ET r191: [JWR] [JSS/JLS] Allow potentially faster charging in host mode, re-add manual host mode
4.3: 2013.10.22 2204ET r191-CM: [JWR] [JSS/JLS] ^ + 2 "CAF" commits for CM compatibility
4.3: 2013.10.09 2148ET r190: [JWR] [JSS/JLS] Re-enable USB debug messages
4.3: 2013.10.01 1954ET r188: [JWR] [JSS/JLS] Zipalign framework-res.apk
ziddey-otg-r183-09141713.zip ziddey-otg-r183-JSS-09141713.zip Add SECONDARY_STORAGE env., do ramdisk patching during flash, include CIFS module -- rebase to r183.
ziddey-otg-r182-09041823.zip ziddey-otg-r182-JSS-09041823.zip Remove module unloading support, patch handheld_core_hardware.xml -- rebase to Franco r182.
ziddey-otg-r178-08240234.zip ziddey-otg-r178-JSS-08240238.zipDisable modversions, enable kernel wakelock stats-- rebase to Franco r178.
JSS15J 4.3.0 2013.08.13 1533ET: ziddey-otg-r174-08131533.zip First release for JSS15J. Updated to 4.3's new unified fstab (native mounting support). Using an "anyramdisk" method for compatibility with different ROMs (specifically, different su implementations). Based off Franco r174.
2013.07.29 1101ET: ziddey-otg-r165-07291101.zip Maintenance build-- rebase to Franco r165.
2013.07.14 2015ET: ziddey-otg-r163-07142015.zip Allow automatic host mode without charging-- rebase to Franco r163.
2013.07.08 1420ET: ziddey-otg-r162-07081420.zip Update storage_list.xml for compatibility with new CM nightlies-- rebase to Franco r162.
2013.06.28 1551ET: ziddey-otg-M3-06281551.zip Maintenance build-- rebase to Franco M3.
2013.06.27 0427ET: ziddey-otg-r156-06270427.zip Re-enable read-only NTFS support in kernel.
2013.06.06 1736ET: ziddey-otg-r151-06061736.zip Releases will now include modules ff-memless.ko, hid-dr.ko, hid-logitech.ko, and xpad.ko (/system/lib/modules). Manually insmod as needed or create an appropriate init.d script to load on boot. Rebase to Franco r151.
2013.05.25 0749ET: ziddey-otg-05250749.zip Fix compatibility issue with CWM (MTP crashes).
2013.05.23 2119ET: ziddey-otg-05232119.zip Start charging immediately when entering host mode. This resolves issues with proprietary chargers.
2013.05.22 2305ET: ziddey-otg-05222305.zip Rebase to Franco's r140. Revert checks for actual proprietary chargers in favor of manually disabling automatic host mode (temporary). Issue "# echo disable > /sys/kernel/debug/msm_otg/aca" to disable automatic host mode (enable to re-enable).
2013.05.17 0107ET: ziddey-otg-05170107.zip Added check for other proprietary charger case. Rebase to Franco's r137.
2013.05.15 0124ET: ziddey-otg-05150124.zip Attempt to detect actual proprietary chargers (Apple-compatible) and charge properly. Rebase to Franco's r136.
2013.05.09 1729ET: ziddey-otg-05091729.zip Should now patch precompiled storage_list.xml to address incorrect strings (Internal Storage/USB Storage). Re-enabled verbose usb debugging messages (dmesg).
2013.05.06 1846ET: ziddey-otg-05061846.zip Maintenance build. Based off Franco's current nightlies branch (r134?). Updated storage_list.xml to match current CM nightlites. Removed freshen flag to hopefully address issues with framework-res.apk not being patched (thanks sga999). Verbose usb debugging messages not enabled (unaltered r134 config)
2013.04.07 0355ET: ziddey-otg-04070355.zip Now modifies /system/etc/permissions/platform.xml to allow app write access to usb storage (thanks garyd9 for script code). Kernel build number reverted to 105 to match Franco's M1 build number.
2013.03.27.2338ET: ziddey-otg-03272334.zip Allow host mode when slimport connected (must manually enable for now. not sure if it actually works, so please report results.) Prevent forced host mode from entering suspended state so it won't get stuck (perhaps worth reinvestigating if we ever get internal power working). Allow forcing mode via /sys/kernel/debug/msm_otg/mode regardless of current state (original code had conditions that were unreasonable. it is designed to be used for debugging after all..). Forgot to reset the build number; should be 105. Would only potentially matter if using Franco's app.
2013.03.23 2000ET: ziddey-otg-03231951.zip All-in-one update now enables android api for usb host mode. Should automatically rescan media library when usb storage is connected. Kernel updated to Franco M1 (milestone), and will probably stay here for a while.
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
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 (manually update vold.fstab accordingly). Based on Franco's git as of 3/12 (after r102)
2013.03.11 2244ET: otg_boot_r3.img Interim build to address wall charging issues (do not attach/detach devices while otg cable connected to phone)
2013.03.09 0739ET: otg_boot_r2.img Should charge (faster) in host mode
2013.03.08 1128ET: otg_franco.zip Initial release in this thread.
2013.03.07 1350ET: franco-otg-201303071328.img "Pre-alpha" build posted in CaptainMuon's thread. Forces disabling of host mode on device unplug.
2013.03.07 1102ET: franco-otg-201303071032.img "Pre-alpha" build posted in CaptainMuon's thread. Forces host mode on detection of "proprietary" type charger (vs usb = sdp, wall = dcp).
References:
Typical Configuration Examples | Android Developers: http://source.android.com/devices/tech/storage/config-example.html
External Storage Technical Information | Android Open Source: http://source.android.com/tech/storage/
chainfire[dev~blog] - Is Google blocking apps writing to SD cards?: http://www.chainfire.eu/articles/113/Is_Google_blocking_apps_writing_to_SD_cards_/

---

Re: [OTG] [08MAR13] [DIRTY HACKS] OTG Kernel / Ramdisk / Framework (Seeking Devs)
Just for clarification this still requires external power via a y cable right?
Sent from my Nexus 4 using XDA Premium HD app

---

Yes, still requires external power. Currently, the hack triggers host mode when detecting "USB_PROPRIETARY" charger.

---

ziddey, is it possible for you to make a framework file for the stock rom? Also, you've given us .img files before. I'm assuming we can flash these .zip files during recovery (e.g. twrp)?
EDIT: I just tried this without the framework file since I'm on stock rom. I flashed the kernel through twrp, but the otg_vold zip would not flash (just said "failed"). Maybe it's not supposed to?. I manually put it in /system/etc. Let me know if I should have been able to flash it.
It works as you described, with usbdisk, no stickmount required. However, the phone is no longer charging like it did with your prior kernels. Maybe that should have been expected, but I certainly liked the fact that I had that "feature" before (with my cable from post #40...it did NOT charge with other OTG or Y-cables).
Strange, but a flash drive works, but a microsd card reader does not. It was working with your prior kernels. EDIT: It seems to be finicky, but I can get that microsd card reader to work also.
Thanks so much for your efforts!

---

Re: [OTG] [08MAR13] [DIRTY HACKS] OTG Kernel / Ramdisk / Framework (Seeking Devs)
Nice work man.. Will give a try
Sent from my Nexus 4 using xda app-developers app

---

Made some updates. Should now charge (faster) in host mode.
otg_boot_r2.img: http://d-h.st/Oky Modified kernel/ramdisk based on 3/1 git clone of Franco's kernel

---

an idea
what happens if you make a manual switch for usb host mode? like when we need to plug usb, we change the state?

---

sga999 said:
ziddey, is it possible for you to make a framework file for the stock rom? Also, you've given us .img files before. I'm assuming we can flash these .zip files during recovery (e.g. twrp)?
Click to expand...
Click to collapse
Gone back to image files again. One less step to do this way.
EDIT: I just tried this without the framework file since I'm on stock rom. I flashed the kernel through twrp, but the otg_vold zip would not flash (just said "failed"). Maybe it's not supposed to?. I manually put it in /system/etc. Let me know if I should have been able to flash it.
Click to expand...
Click to collapse
You're right; I hadn't tested it, and assumed I'd be able to just hack up a different zip for use. Pulled it for now.
It works as you described, with usbdisk, no stickmount required. However, the phone is no longer charging like it did with your prior kernels. Maybe that should have been expected, but I certainly liked the fact that I had that "feature" before (with my cable from post #40...it did NOT charge with other OTG or Y-cables).
Click to expand...
Click to collapse
I'm surprised you didn't have issues with the prior builds. I don't think I ever changed anything. That said, it should be fixed now. Let me know how it works.
Strange, but a flash drive works, but a microsd card reader does not. It was working with your prior kernels. EDIT: It seems to be finicky, but I can get that microsd card reader to work also.
Click to expand...
Click to collapse
Likely an issue on your end since I don't think anything was changed that would cause this. Are you trying to use both the flash drive and microsd at the same time? I'm not sure how that'd be handled-- upon insertion of the second drive, either nothing happens, or it overloads the first drive. As it is, I'm guessing my implementation of usbdisk isn't properly done.
Thanks so much for your efforts!
Click to expand...
Click to collapse
No problem! More of a personal challenge/desire. Really hoping that a real dev takes notice.

---

ereghro said:
what happens if you make a manual switch for usb host mode? like when we need to plug usb, we change the state?
Click to expand...
Click to collapse
You mean like CaptainMuon's build, where you change /sys/kernel/debug/msm_otg/mode?
Originally, there were issues with that method after unplugging the OTG cable, but that may have been fixed with the hacks to the OTG_STATE_A_IDLE case. It's possible that the other modifications will now cause problems with with the debug mode, but I'm imagining it just makes it unnecessary (except for debugging purposes) since it's not actually triggering a_host based on the ID pin, but rather by the detected charger.
Is there a particular reason you want to use a manual switch? I can re-enable it in the next build.

---

ziddey said:
Gone back to image files again. One less step to do this way.
You're right; I hadn't tested it, and assumed I'd be able to just hack up a different zip for use. Pulled it for now.
I'm surprised you didn't have issues with the prior builds. I don't think I ever changed anything. That said, it should be fixed now. Let me know how it works.
Likely an issue on your end since I don't think anything was changed that would cause this. Are you trying to use both the flash drive and microsd at the same time? I'm not sure how that'd be handled-- upon insertion of the second drive, either nothing happens, or it overloads the first drive. As it is, I'm guessing my implementation of usbdisk isn't properly done.
No problem! More of a personal challenge/desire. Really hoping that a real dev takes notice.
Click to expand...
Click to collapse
ziddey, I don't think you answered about me wanting a stock version of framework-res. I tried to create it with the Framework Flasher that you suggested, and it seemed to complete successfully. But when I flash it, it stops at the Nexus 'X' logo...it does a little vibration every minute or so, but never comes out of that. I even used that same tool to decompile, recompile WITHOUT any changes, sign it, etc., but the result is the same. So....either the tool isn't really working or I'm doing something else wrong. Any special instructions on how to flash the update.zip...or what it must be flashed with? I tried flashing it alone, then tried with your kernel (2 separate steps in twrp).
I haven't had enough time yet to get in much testing, but YES! Charging has returned!
No, I'm not trying both devices at the same time, so I don't know what is going on with the microsd. I'll keep trying to figure it out.
I'd like to know how to see logs of what's going on, like when you say there is "overload" (or other problems). Can you tell me what you're looking at to see errors, status, etc.?
I understand how you feel about the personal challenge. I'm that way too....I love to see things work and won't quit! But unfortunately, I don't have the expertise to help you here. But I'll certainly test it! I can't understand why dev's aren't joining you. And I may be the only one downloading your files (based on counts on dev-host). Very strange.

---

Did you update the apktool components? The components in wesf90's Framework Flasher (http://forum.xda-developers.com/showthread.php?t=1432152) are old and don't support JB4.2.
Down the new apktool and dependencies from http://code.google.com/p/android-apktool/downloads/list and replace the ones in wesf90's kit. That's all I did, and it seemed to work fine for me.

---

ziddey said:
Did you update the apktool components? The components in wesf90's Framework Flasher (http://forum.xda-developers.com/showthread.php?t=1432152) are old and don't support JB4.2.
Down the new apktool and dependencies from http://code.google.com/p/android-apktool/downloads/list and replace the ones in wesf90's kit. That's all I did, and it seemed to work fine for me.
Click to expand...
Click to collapse
I updated apktool and aapt. And everything ran perfectly. Most people who had not updated yet said it failed somehow, then after updating, it worked. But I updated the tools first, never got errors, so I think it's creating the update.zip properly. So I'll ask this one more time, and if you don't want to or can't do this, please let me know. Can you create the framework-res.apk zip file for the stock rom for me? Maybe I would then be able to compare my update.zip to yours and see what went wrong.
If I already have your kernel installed, can I just bring up twrp recovery and flash the single update.zip for the framework? Or is it more complicated than that? I'm thinking I must be missing something about how to flash the update.zip.
Can you tell me how to see logs that show the overload and other issues? Again, please just let me know, and if you don't want to answer this, I'll stop asking.
I appreciate all that you've done, and I certainly don't want to ask you too much. I just need to know if you're missing the questions or don't want to answer...which is fine.

---

sga999 said:
I updated apktool and aapt. And everything ran perfectly. Most people who had not uproperlyyet said it failed somehow, then after updating, it worked. But I updated the tools first, never got errors, so I think it's creating the update.zip properly. So I'll ask this one more time, and if you don't want to or can't do this, please let me know. Can you create the framework-res.apk zip file for the stock rom for me? Maybe I would then be able to compare my update.zip to yours and see what went wrong.
If I already have your kernel installed, can I just bring up twrp recovery and flash the single update.zip for the framework? Or is it more complicated than that? I'm thinking I must be missing something about how to flash the update.zip.
Can you tell me how to see logs that show the overload and other issues? Again, please just let me know, and if you don't want to answer this, I'll stop asking.
I appreciate all that you've done, and I certainly don't want to ask you too much. I just need to know if you're missing the questions or don't want to answer...which is fine.
Click to expand...
Click to collapse
Sounds like the update script is fine, the problem is with your framework. Either it's not being recompiled properly or the changes you're making are causing problems. What versions of the tools are you using?

---

So if this requires external power, would an external hdd with external power source work, in theory? Or does the USB itself need to carry a current to make it work?

---

MWBehr said:
Sounds like the update script is fine, the problem is with your framework. Either it's not being recompiled properly or the changes you're making are causing problems. What versions of the tools are you using?
Click to expand...
Click to collapse
I've tried it with no changes at all, i.e. decompile and recompile with no changes (my post #11 describes this in more detail). So as you said, the recompile must not be working.
My versions are:
aapt.exe v0.2
apktool.jar 1.5.2 but unfortunalely, frameworkflasher's runme.bat always does "echo version 1.4.3" (this threw me off for a while!)
I only replaced aapt.exe and apktool.jar. Are there other .exe or .dll files that need to be replaced also? Maybe I'm just doing an incomplete job of updating the files.
Thanks for your help.

---

sga999 said:
Can you create the framework-res.apk zip file for the stock rom for me?
Can you tell me how to see logs that show the overload and other issues?
Click to expand...
Click to collapse
Upload your framework-res.apk and I'll try to mod it. Not sure why it's not working for you though.
I haven't combed through the logs to look for when it's mounted, but since you created vold.fstab, it shouldn't be an issue. Maybe it didn't affect the stock rom anyway. If it did mount at /mnt/shell/emulated/0, internal storage would no longer be accessible. I had issues even opening Android settings, nevermind storage. Of course, you could simply check your mounts with the mount command, or use df to see mounts / disk space.
hp420 said:
So if this requires external power, would an external hdd with external power source work, in theory? Or does the USB itself need to carry a current to make it work?
Click to expand...
Click to collapse
In theory, yes. However, I'm imagining that a powered external hdd isn't going to be sending power out the usb port, and since the charger type is currently used to force host mode, it won't switch automatically. This could be a potential reason for the debug /sys/kernel/debug/msm_otg/mode, so I'll enable it in the next build. Unfortunately, I'm imagining that it still won't work though, seeing how it'd get stuck in a_idle. However, it does give me some ideas for trying to trace the root issue, or at least figuring out another workaround.

---

ziddey said:
Upload your framework-res.apk and I'll try to mod it. Not sure why it's not working for you though.
Click to expand...
Click to collapse
ziddey, here are links to my framework-res.apk and the update.zip. They are unmodified stock, i.e. I let framework flasher decompile, recompile without any changes, sign, etc. You may have no interest in the update.zip, but if what you create "matches" mine (not sure if a byte by byte compare will work), I don't think it will help for you to give yours to me. But again, just ignore that .zip if you want to.
I'm not very familiar with uploading, so if I'm not supposed to put direct links here, let me know.
http://www.mediafire.com/?wxcnozb2e5u8wps
http://www.mediafire.com/?visp1jzai8aqisp
What I mean about the log is that I don't know what log you look at. I know there's logcat, dmesg, maybe others, but I've never looked at them. So I wanted to learn a little more by looking at the same thing you look at when you notice various errors.
Thanks for your help.

---

edit: DO NOT DOWNLOAD. Tested by sga999 and does not work.
http://d-h.st/Z2s md5sum: 2b07609be9c462a0f4ba54c141dc2e88
your update.zip db087c101a8c07aa3606102128c96051
mine 19642b12da5a6fd372280c3e33fa8247
Report if that works. May be of interest to others. Is that stock 4.2.2 JDQ39?

---

ziddey said:
http://d-h.st/Z2s md5sum: 2b07609be9c462a0f4ba54c141dc2e88
your update.zip db087c101a8c07aa3606102128c96051
mine 19642b12da5a6fd372280c3e33fa8247
Report if that works. May be of interest to others. Is that stock 4.2.2 JDQ39?
Click to expand...
Click to collapse
Yours fails also! I have given it about 6 minutes, and it's stuck on the 'X'. I've waited longer than that before, maybe 10 minutes, but I don't ever think it should take more than a couple of minutes, right? UPDATE: I've now waited 11 minutes.
Yes, I gave you /system/framework/framework-res.apk from stock 4.2.2 JDQ39. That's what I'm running.
I have the unsigned and signed apk's saved from the various steps of Framework Flasher. It would be interesting to know where it goes wrong. I'm pretty sure the signed apk has the same problem, but I can't be sure I installed it properly (I read various posts about putting it in /system, fixing properties, cut/paste into /system/framework). It reboots immediately after I do the paste.
I would guess that the recompile is somehow not working. I suppose I could try to go through the individual steps on my own...but I sure had hoped to use this tool, just like you did!
Thanks for creating it for me...at least it's not something I was doing wrong with the tool!