[Galaxy S 5 Original Android Development] BruceElliott:
Hi All,

Behold supreme stupidity, resulting in my phone having been down for over three weeks now:

Using an earlier version of the BK Disabler app, which exposes individual services within each app and permits selectively disabling services, I was a bit too aggressive and disabled some system app(s) and/or service(s) required for booting the phone. The phone boots through the Android sequence, displays the TMO boot screen, sounds the TMO boot jingle, and then freezes and overheats if left in that state, requiring battery removal.

After recovering my data and taking a full nandroid backup using TWRP (bless you, Team-Win!), I flashed the latest version of the S5 stock ROM (dated March 2017, downloaded from Sammobile), which is what I had on my phone when I bricked it. That indeed restored boot and and left me at the new phone startup procedure and back at the dreaded beginning of a system configuration oddessy that has evolved over years.

In an attempt to shortcut a repeat of that oddessy, I flashed only the /data partition from the nandroid backup. But of course the /data partition backup includes all apps and their settings, including BK Disabler and its XML file of disabled apps, including the disabled system apps preventing boot. So now my phone is back at an unbootable state; but at least I know that the problem is in the /data partition. Using the terminal app in TWRP, I found BK Disabler in /data and its dependent files in /data/data. I have not yet found BK Disabler's XML file, which lists all of the disabled apps. Once I do, I will delete those entries, rename BK Disabler apk and files, and create a nandroid of the resulting "old" /data partition minus BK Disabler. Then I will flash the entire stock ROM again from Odin, but without reboot. As I understand it, at first boot the system creates the master "oat" file from apps in the /data partition (during the period following first boot when it shows a progress bar and counts up the system apps). Subsequently the system modifies the master oat file as new apps are properly installed. If that is indeed the way it works, it makes sense that one could not abruptly restore a /data partition that does not match what the rest of the system is expecting.

To recap, I will flash back to stock, but this time without reboot. I will then flash the backup /data partition with all of my "old life" apps and app data, but hopefully minus the offending BK Disabler apk and dependent files. Then, when I boot to this jury-rigged system for the first time, hopefully the new phone startup process will be happy with the modified /data partition and go merrily on its way by creating the system oat file to include all of my old apps, etc. I even found the system settings file in /data/data, so if this works, hopefully even those will be retained.

Another, more laborious process, would be to try to find all of the system executables whose "execute" permission were set to "no execute" by BK Disabler and use the Chmod command in TWRP to restore those permissions. This might be more likely to succeed, given that all of the old system would be as it was when it bricked, except that whatever system files are causing the bricking would have their "execute" permissions restored.

Can the community please help me with the following questions (which will reveal my noobiness with SeLinux bash):

(1) Is the limited Linux bash command set available at TWRP 3.2.1-0 "Advanced" ------> "Terminal"/"File Manager" able to help me find system files whose "execute" permission is set to "no execute"? If so, it appears that I could use the Chmod button to re-enable execution.

(2) What would be a proper bash command syntax (e.g., including grep filters) to search for files with the "execute" permission set to "no execute"? (I would be looking in /data and in /data/data, right?)

(3) Having merely flashed TWRP without yet rooting, I am amazed that I can see as much of the root directory tree as I can in TWRP terminal. Do I need to root in order to change system file permissions in /data and child directories thereof? If I change permissions using the TWRP File Manager "Chmod" button, could I (blindly) change the 4-octet permissions sequence to, say "4666" to re-enable "execute" on the disabled system executables?

(4) Otherwise, what bash sequence to I need to determine all of the file permissions for each of the subset of files found in step (2)? That way, I could more intelligently use Chmod to re-enable "execute" without changing the other permissions (e.g., "read", "write," etc.).

(5) Otherwise, if someone can suggest a bash command syntax to do nothing except re-enable the "execute" permission rather than using the Chmod button, that would be fine too.

Forgive the noobiness of all of this, and please know how much I appreciate any help that the community is able to provide.

Well wishes to all,

Bruce