Pardon me for my drive-by here
, but just wanted to post a few quick observations (many of which have already been mentioned by
@EarlyMon and
@SuperR) :
1. I've seen "E:Error executing updater binary in zip..." error message (in post #17) before and pretty sure it's related to an incomptabible update-binary for the kernel (i.e., TWRP's custom recovery in this case). Changing to a known / different update-binary (i.e., that you've used in/for another flashable .zip) might help. Think this is where
@EarlyMon was going when he provided the link to an alternate update-binary.
2. The "E:mount -o binary '/data/media/0' '/sdcard' process ended with ERROR=255" in post #23 looks like TWRP doesn't understand how to mount the internal "SD card" storage for this device.
3. Posting-up the /cache/recovery/last_log and/or /tmp/recovery.log as
@SuperR suggested when the issues are happening would be helpful to clarify / point-point things. That will give more details and context as to what TWRP might be doing at that time.
4. Entering an adb shell while custom recovery (TWRP) is launched and manually entering the commands that you'd like to be accomplished could (should) help you identify what the core issue is (understanding that you can't use the exact/same commands from the updater-script here, but you'll have to use the shell equivalents). Thus, you could build-out an installation script file that could either replacing the function that's not working (as
@EarlyMon already suggested).
5. Also, as an added debugging/testing feature, you can manually invoke the update-binary from a rooted shell (in custom recovery or not):
META-INF/com/google/android/update-binary
The update-binary can be found in any upgrade.zip file in the location shown above; it is a parser for updater-script found in the same directory.
There is no signature checking in update-binary; recovery performs a signature check over the entire upgrade.zip file and anything inside is presumed safe. The upshot of this is that update-binary can be rebundled into a new zip file and updater-script for used with a custom recovery, or update-binary can be manually executed by the user on a custom zip file. This is useful since the update-binary often contains functions that would otherwise be difficult such as baseband upgrades.
update-binary <api> <pipefd> <zip>
The api is 3, the pipefd is the descriptor used by recovery, the zip file file is the zip file containing the updater-script to be executed. (The update-binary within the zip file is ignored)
(the original thread/page is no longer alive, but you can use
this Internet Wayback URL to get there)
This would allow you to test different update-binary files against the same .zip files.
I've often used this to test some update-script files (being very careful if you're doing this in normal Android).
You could plop different versions of the update-binary executable in /cache, secure them with chmod, and execute them from there (i.e.,
/cache/update-binary-test 3 0 /cache/test1.zip).
Cheers and I hope something from the above might elicit a solution.
