[LG V20 Guides, News, & Discussion] hotcell:
3rd Feedback

I never do posts asking or hoping for likes. That would be rather strange assumption. Regarding your obviously negative connotation here, it would be more appropriate if you simply remove the "like" you made.

Thank you for more detailed explanation. I have to note that you added the explanations in your post #3

after

I asked the relevant net policy questions. Either way, IMHO your statement "I think the performance loss or gain is debatable, totally dependant on how Android internally implemented it, and, frankly, this is something I don't wish to get heavily involved with. Please kindly, keep me out of future debates." is not very encouraging. To me it seems that you aren't interested in the discussion of benefits in performance or possible battery savings here, thus logically negating the major possible purpose of using your tool from users perspective. That's strange indeed, but I do respect your wish, so that's it.

Here you are contradicting yourself. As you previously mentioned, you made a deliberate effort to ensure any script can be renamed and still maintain its integrity thus boosting flexibility of usage even more. But here you are basically insisting such move would not be practical. In previous post I suggested you to maintain this flexibility by introducing renaming templates file, so updating the tool will be a simple seemless step/command, without manual intervention required, regardless of a chosen naming scheme. Well, again, it's your call. Perhaps you'd reconsider, just like you did with the inner AST folder in the distribution archive (Thanks BTW for that!).

Indeed I mentioned this due to failure to obtain the expected result on execution of ast.install. Note this script can't be run from ext SD card due to the obvious permission / media format issue. But, normally the /system is in RO state, so even if jackterm has required root permission, the ast.install still would fail when run from internal storage:

elsa:/storage/emulated/0/Download/ast #sh ast.install /system/xbin

cp: /system/xbin/ast.ls: Read-only file system

chmod: chmod '/system/xbin/ast.ls' to 100755: Read-only file system

cp: /system/xbin/ast.net: Read-only file system

chmod: chmod '/system/xbin/ast.net' to 100755: Read-only file system

cp: /system/xbin/ast.pm: Read-only file system

chmod: chmod '/system/xbin/ast.pm' to 100755: Read-only file system

cp: /system/xbin/ast.ops: Read-only file system

chmod: chmod '/system/xbin/ast.ops' to 100755: Read-only file system

cp: /system/xbin/ast.set: Read-only file system

chmod: chmod '/system/xbin/ast.set' to 100755: Read-only file system

cp: /system/xbin/ast.sto: Read-only file system

chmod: chmod '/system/xbin/ast.sto' to 100755: Read-only file system

cp: /system/xbin/astcore: Read-only file system

chmod: chmod '/system/xbin/astcore' to 100755: Read-only file system

I) ast.install: Installation completed.

elsa:/storage/emulated/0/Download/ast #

Why and how reboot supposed to resolve that?

EDIT: Looks like it works fine when performed right

after reboot

! It would be nice if install script would try to perform a mount, cp, chmod and report about the failure. Instead of showing the (fake) message "Installation completed." the hint to reboot and retry would be much more useful.

It has nothing to do with wrong impressions. All I tried to suggest was an attempt to provide a path to easy and working solution to install/update AST and have a workaround for system RO state issue as described above. One still will have to ensure the system partition is mounted in TWRP before doing AST install/update. Sure if ast.install or its exec environment can be fixed, there would be no need to reboot to recovery or perform manual steps with a file manager.

If and when I'll proceed with net policy customisation and start to have some comarative data on battery consumption, I'll try to post here without involving you to the subject as per your wish to keep you out of future debates.