-
After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.
Mods updater-script needs help [Root only]
- Thread starter HasH_BrowN
- Start date
WarrantyVoider
Android Enthusiast
Great tip! Had I known about this when I started, it would've saved me a lot of time.
By the way, should "update-binary 3 0 test.zip" be "update-binary 3 1 test.zip"? Since stdout is fd 1...
Great tip! Had I known about this when I started, it would've saved me a lot of time.
By the way, should "update-binary 3 0 test.zip" be "update-binary 3 1 test.zip"? Since stdout is fd 1...
Thanks! I felt the same way when I found it a few years back
.Not sure about the fd 0 vs. fd 1...I've always used fd 0 without issue, but I can try/test it tonight just to see (I remember reading/reviewing the source re. that, but nothing stood out to me).
WarrantyVoider
Android Enthusiast
You're probably right. Arguments to update-binary are meant to interface with the recovery environment, so perhaps their meanings aren't what I expect. I've been using shell scripts in place of update-binary myself, so I haven't bothered with an actual update-binary for a while...
HasH_BrowN
Android Expert
Oh no, I got both of you here.
Between the both of you, I should end up knowing everything about scripting.
I'm going to have to get my ass in gear.
Let me run with what you gave me, have to get that figured out and then incorporate it into existing work. But I'll be on track real soon. I'll post back with any questions or issues. Hopefully I'll have something
"slick" and "beautiful" to show you.
Between the both of you, I should end up knowing everything about scripting.
I'm going to have to get my ass in gear.
Let me run with what you gave me, have to get that figured out and then incorporate it into existing work. But I'll be on track real soon. I'll post back with any questions or issues. Hopefully I'll have something
"slick" and "beautiful" to show you.
HasH_BrowN
Android Expert
I was taking a breather for a minute and was wondering. In order for me to find the "fota" and "misc" on other devices, would it be as simple as cat /proc/mounts. I understand that it might be called something different on varying devices, the location names that need to be zeroed. Or would I have to add a variable to it? Its my understanding that that code will pull directory.
Could the return of the command be cropped/filtered to display particular area simply by adding to the command, ie. cat /proc/mounts/system OR is there a craftier way to acquire it?
I'm trying to digest all this info you've been providing/teaching me. Thank you for your patience, knowledge, and bearing with me on this, @scary alien and @WarrantyVoider.
Back to the grindstone. Catch you guys tonight.
Could the return of the command be cropped/filtered to display particular area simply by adding to the command, ie. cat /proc/mounts/system OR is there a craftier way to acquire it?
I'm trying to digest all this info you've been providing/teaching me. Thank you for your patience, knowledge, and bearing with me on this, @scary alien and @WarrantyVoider.
Back to the grindstone. Catch you guys tonight.
Yeah, not all devices have a "fota" partition...
Also, I'm not sure that clearing the "misc" partition on other devices than the ones you've tested on or had direct access to would fix a bootloop that you described.
In fact, wiping / clearing the "misc" partition on some devices I'm pretty sure would result in an inoperable device
. So, you might need/want to restrict your flashable to certain known devices for the time being...
I've got some code at home on my development PC that I could share with you about how to see/find various partitions. /proc/mounts is one way, but probably for the bulk of fairly-new(er) devices, you can look for the /dev/block/platform/*/by-name directories--not 100% foolproof since some devices do not support that path (or have the name aliases), but you'll get a lot of devices that way.
Also, you'd have to keep in mind the manufacturers don't consistently name (or use) the partitions identically as other companies. For example, "recovery" vs. "SOS", etc..
Also, I'm not sure that clearing the "misc" partition on other devices than the ones you've tested on or had direct access to would fix a bootloop that you described.
In fact, wiping / clearing the "misc" partition on some devices I'm pretty sure would result in an inoperable device
. So, you might need/want to restrict your flashable to certain known devices for the time being...I've got some code at home on my development PC that I could share with you about how to see/find various partitions. /proc/mounts is one way, but probably for the bulk of fairly-new(er) devices, you can look for the /dev/block/platform/*/by-name directories--not 100% foolproof since some devices do not support that path (or have the name aliases), but you'll get a lot of devices that way.
Also, you'd have to keep in mind the manufacturers don't consistently name (or use) the partitions identically as other companies. For example, "recovery" vs. "SOS", etc..
HasH_BrowN
Android Expert
No, I realized that the names/locations would most definitely different. I wish they were the same. This would've been easy then. LolYeah, not all devices have a "fota" partition...
Also, I'm not sure that clearing the "misc" partition on other devices than the ones you've tested on or had direct access to would fix a bootloop that you described.
In fact, wiping / clearing the "misc" partition on some devices I'm pretty sure would result in an inoperable device
I've got some code at home on my development PC that I could share with you about how to see/find various partitions. /proc/mounts is one way, but probably for the bulk of fairly-new(er) devices, you can look for the /dev/block/platform/*/by-name directories--not 100% foolproof since some devices do not support that path (or have the name aliases), but you'll get a lot of devices that way.
Also, you'd have to keep in mind the manufacturers don't consistently name (or use) the partitions identically as other companies. For example, "recovery" vs. "SOS", etc..
HasH_BrowN
Android Expert
Can an (*) be used as a wild card?? Hmm... , I never tried that.
Did it real quick in terminal emu. Nope, doesn't work.
Okay I gotta stop looking at my phone.
Last edited:
Depends on the context...but, yes
.A shell "ls" (list) command will work if it doesn't return too much info (not likely to overflow it's buffer, so you're probably safe). Also, the find utility will work.
HasH_BrowN
Android Expert
Ill try in a bit again, but differently than I did.
Couple of examples / options for you (note: I purposely tried to list things while not rooted just to point-out that root will likely be needed for this):
HasH_BrowN
Android Expert
I didn't know (think) about the busybox cmd.Couple of examples / options for you (note: I purposely tried to list things while not rooted just to point-out that root will likely be needed for this):
HasH_BrowN
Android Expert
If have been real busy, will post back when I completed the teacher(s) lessons.
Just bear with me, I really do want accomplish this the right way.
Just bear with me, I really do want accomplish this the right way.
HasH_BrowN
Android Expert
Well I tried multiple things and still getting failed binary errors, I've changed multiple binaries out and rewrote the script a dozen times (plus all the user failed installs). I'm stumped.No worries or hurry, HasH_BrowN
Do you see where my error might be (with the download resource)? Even with different logfiles I'm still not able to narrow it down.
HasH_BrowN
Android Expert
I'm understanding how to get (future update) arguments and variables, just not the commands for the bootloop fix to execute.
Which specific link can I find it it (or can you post/attach it here)?
Usually the update-binary errors are caused by simple syntax errors or having carriage-returns included in the script.
Point me to the .zip and I'll take a peek at it for you
.
HasH_BrowN
Android Expert
Sorry, I forgotWhich specific link can I find it it (or can you post/attach it here)?
Usually the update-binary errors are caused by simple syntax errors or having carriage-returns included in the script.
Point me to the .zip and I'll take a peek at it for you
http://androidforums.com/resources/twrp-bootloop-fix-zip.214/
Thanks!
So, does this version have an issue (you get errors with this version)?
So, does this version have an issue (you get errors with this version)?
HasH_BrowN
Android Expert
Yes, failed every time.Thanks!
So, does this version have an issue (you get errors with this version)?
HasH_BrowN
Android Expert
It did pass in the HBlog script.Thanks!
So, does this version have an issue (you get errors with this version)?
HasH_BrowN
Android Expert
Tell me if I'm wrong, but to try to make this non-device reliant I would have to make this a sh styled script (of course with proper references, variables, and arguments). Otherwise binary would only work for this device (LG LS660). Correct??
Okay, don't be mad at yourself...
You're missing a closing paren on your first assert line:
assert(getprop("ro.product.device") == "e2nas" || getprop("ro.build.product") == "e2nas" || abort("I'm sorry, but this package is for \"e2nas\" devices until more testing is done; this is a \"" + getprop("ro.product.device") + "\".");
just needs to be:
assert(getprop("ro.product.device") == "e2nas" || getprop("ro.build.product") == "e2nas" || abort("I'm sorry, but this package is for \"e2nas\" devices until more testing is done; this is a \"" + getprop("ro.product.device") + "\"."));
Your update-binary worked just fine on my Nexus 5, by the way.
You're asking how to make your flashable run on a wider range of devices?
If so, then you certainly would/should have more flexibility in using a shell script since coding would be much easier (IMO) than the Edify syntax/language.
Like I (think?) I mentioned before, your biggest challenge would be in identifying the "fota" and "misc" partitions, but there are ways to find the obvious references.
The scary part to me is knowing that it would be proper to clear those partitions on a given device...I'm still pretty on the fence about that (and the "fota" and "misc" partitions aren't ones that are typically backed-up with a Nandroid backup, either, so if they become wiped, how do you get them restored, etc...?