• 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]

scary alien said:
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...?
Click to expand...
True. The needed partition locations would absolutely be tested with all parties knowledgeable of bricking possibilities.
 
scary alien said:
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.
Click to expand...
Oh I'm gonna kick my ass.

Really a )? It worked?
Aww, I'm relieved.

Thanks a bunch.
 
HasH_BrowN said:
Oh I'm gonna kick my ass.

Really a )? It worked?
Aww, I'm relieved.

Thanks a bunch.
Click to expand...

Yep! :)

I substituted "hammerhead" for "e2nas" in the updater-script file that I actually tested. I got errors, too, until I added the closing paren ;).

root@hammerhead:/cache/hb # /cache/hb/update-binary 3 0 /sdcard/hbtest.zip
/cache/hb/update-binary 3 0 /sdcard/hbtest.zip
ui_print
ui_print *********************************
ui_print
ui_print *Bootloop is fixed. Just reboot.*
ui_print
ui_print *********************************
ui_print
ui_print This was made by HasH_BrowN and the zip
ui_print
ui_print was made possibly with help from
ui_print
ui_print WarrantyVoider & scary alien.
ui_print
ui_print Please visit my thread for the bootloop fix @
ui_print
ui_print http://androidforums.com/threads/twrp-bootloop-fix-after-update-ota.922585/
ui_print
script result was [http://androidforums.com/threads/twrp-bootloop-fix-after-update-ota.922585/]
root@hammerhead:/cache/hb #
 
scary alien said:
Yep! :)

I substituted "hammerhead" for "e2nas" in the updater-script file that I actually tested. I got errors, too, until I added the closing paren ;).

root@hammerhead:/cache/hb # /cache/hb/update-binary 3 0 /sdcard/hbtest.zip
/cache/hb/update-binary 3 0 /sdcard/hbtest.zip
ui_print
ui_print *********************************
ui_print
ui_print *Bootloop is fixed. Just reboot.*
ui_print
ui_print *********************************
ui_print
ui_print This was made by HasH_BrowN and the zip
ui_print
ui_print was made possibly with help from
ui_print
ui_print WarrantyVoider & scary alien.
ui_print
ui_print Please visit my thread for the bootloop fix @
ui_print
ui_print http://androidforums.com/threads/twrp-bootloop-fix-after-update-ota.922585/
ui_print
script result was [http://androidforums.com/threads/twrp-bootloop-fix-after-update-ota.922585/]
root@hammerhead:/cache/hb #
Click to expand...
Cool. I just fixed the file and flashed it too, and it passed.
What's funny is, previously I deleted the assert and it failed.
 
scary alien said:
Yep! :)

I substituted "hammerhead" for "e2nas" in the updater-script file that I actually tested. I got errors, too, until I added the closing paren ;).

root@hammerhead:/cache/hb # /cache/hb/update-binary 3 0 /sdcard/hbtest.zip
/cache/hb/update-binary 3 0 /sdcard/hbtest.zip
ui_print
ui_print *********************************
ui_print
ui_print *Bootloop is fixed. Just reboot.*
ui_print
ui_print *********************************
ui_print
ui_print This was made by HasH_BrowN and the zip
ui_print
ui_print was made possibly with help from
ui_print
ui_print WarrantyVoider & scary alien.
ui_print
ui_print Please visit my thread for the bootloop fix @
ui_print
ui_print http://androidforums.com/threads/twrp-bootloop-fix-after-update-ota.922585/
ui_print
script result was [http://androidforums.com/threads/twrp-bootloop-fix-after-update-ota.922585/]
root@hammerhead:/cache/hb #
Click to expand...
Is it okay to release the new "improved" [w/ a)] zip?
 
I came across a file_context, on XDA LG G3 forum, that checks each part of the misc partition against the system. Seems many (read multiple) LG devices can use this. Going to scan over it and see how its implemented. Will post back after discovery. This would be awesome to get incorporated into my zip.
The XDA LG G3 OP said this (the file_context) is possibly from CM. How do i find out if it is theirs? I didnt see any reference to them is the file. What/how do i ask for permission if it is theirs? (Sorry I'm a noob, never had to ask yet)
 
Last edited:
HasH_BrowN said:
I came across a file_context, on XDA LG G3 forum, that checks each part of the misc partition against the system. Seems many (read multiple) LG devices can use this. Going to scan over it and see how its implemented. Will post back after discovery. This would be awesome to get incorporated into my zip.
The XDA LG G3 OP said this (the file_context) is possibly from CM. How do i find out if it is theirs? I didnt see any reference to them is the file. What/how do i ask for permission if it is theirs? (Sorry I'm a noob, never had to ask yet)
Click to expand...
I should add that the OP of the XDA thread didnt give credit to CM for the file....
 
Code: 
#!/bin/bash
#
#create a file to work with
#
echo "creating a file to work with"
dd if=/dev/zero of=/var/tmp/infile count=1175000

for bs in 1k 2k 4k 8k 16k 32k 64k 128k 256k 512k 1M 2M 4M 8M

do
        echo "Testing block size = $bs"
        dd if=/var/tmp/infile of=/var/tmp/outfile bs=$bs
        echo ""
done
rm /var/tmp/infile /var/tmp/outfile
@scary alien
I found a script for Linux to determine a good byte size. My question would be "How or what do i need to change to work for Android?"
Obviously lines 6, 12, and 15 need to be edited for locations. Not sure if count is correct in line 6. Also not sure on line 8 if i included all correct sizes.

I want to use this for getting a good byte size for a backup command that i have for the bootloop fix.
 
I'm guessing you're asking about an optimum byte size for the dd command (ref. http://serverfault.com/questions/147935/how-to-determine-the-best-byte-size-for-the-dd-command) so that your dd operations are efficient?

Are you doing that many dd utility invocations that it really makes that much difference?

The above script should be relatively straightforward to convert to "sh" (if it doesn't work straight out of the box already).

Unfortunately, I'm not sure how the above script actually tells you anything about what is optimal? As one of the replies in the Answer section of the above thread/link indicates, you'd have to add some time/timing commands to the output and interpret which blocksize was indeed the fastest (and therefore, most efficient).

So, IMO, the above script is a bit incomplete [as it stands now, anyways] ;) :p.
 
That was the link i got it from a couple of weeks ago.
Not that many dd cmds, but was wanting more or less for dead on accuracy.
Do you know what the proper bs should be? Ive seriously looked @ 80-90 different pages and NONE deal with Android. We use 4096 blocks, so inode size should be 256????
 
You're going to be using this in a flashable, right? So you're not really competing for other resources (inside the custom recovery's kernel).

I would think/imaging that if you stuck with a "safe" blocksize of 2k or 4k or 8k you'll get very acceptable performance and no compatibility issues with a wide variety of devices that might be running your script.

You can do some manual timing tests with the dd command on a "lower-tier" device and I'm betting even with a low/small blocksize of 4k or 8k, you won't see too much difference (or any that would matter) vs. a new/current/power device (or that the difference is not worth worrying about).
 
So maybe the file isnt needed in such grandiose design, but I can limit it.

Im having a dilemma on permissions. What is proper format for setting permissions recursively for batch extraction to the same directory? I keep running into an error.
Or
Does extracting to /system automatically set permissions?
 
Last edited:
This is the command from the updater script for bs size
Code: 
/sbin/busybox dd if=/dev/zero of=/dev/block/platform/msm_sdcc.1/by-name/misc bs=256 count=1 conv=notrunc;
Is 256 good? I keep coming back to that number.
 
Using set_metadata_recursive (regarding the error/issue you're seeing)?

https://source.android.com/devices/tech/ota/inside_packages.html

set_metadata_recursive(dirname, key1, value1[, key2, value2, ...])
Code: 
Recursively sets the keys of the given dirname and all its children to values.

For example:

set_metadata_recursive("/system", "uid", 0, "gid", 0, "fmode", 0644, "dmode", 0755, "selabel", "u:object_r:system_file:s0", "capabilities", 0x0).
 
scary alien said:
Using set_metadata_recursive (regarding the error/issue you're seeing)?

https://source.android.com/devices/tech/ota/inside_packages.html

set_metadata_recursive(dirname, key1, value1[, key2, value2, ...])
Code: 
Recursively sets the keys of the given dirname and all its children to values.

For example:

set_metadata_recursive("/system", "uid", 0, "gid", 0, "fmode", 0644, "dmode", 0755, "selabel", "u:object_r:system_file:s0", "capabilities", 0x0).
Click to expand...
Thank you
 
You must log in or register to reply here.
Back
Top Bottom