[Galaxy S 4 i9505 Original Android Development] chenxiaolong:
The issue where patched TouchWiz 4.4 ROMs (or after updating the ramdisk) will not boot should be fixed in 8.0.0.r2243.g5f809b2.

(Tagging [MENTION=417657]nutpants[/MENTION] since you ran into this issue)

--------

Since this was a somewhat complicated fix, here's a technical description for those who are interested:

There is a component in Android called 'installd' which handles several tasks related to installing and managing apps (for example, clearing app data and creating the dalvik-cache). It a program that runs as root and waits for commands from the Android framework.

The Android framework usually communicates with the installd daemon with sequential commands. It sends commands, waits for a reply, sends another command, waits for another reply, and so on. This diagram shows how Android normally works:

Framework installd
--------- --------
| -- Start dexopt --------------> |
| <------------ Receive result -- |
| -- Start dexopt --------------> |
| <------------ Receive result -- |
| ............................... |

TouchWiz 4.4 implements asynchronous processing of dexopt (building dalvik-cache) requests on the first boot in order to improve the boot speed. The TouchWiz framework sends the 'asyncDexopt' command, waits for an acknowledgement reply, sends another 'asyncDexopt' command, waits for another acknowledgement, and so on. However, some time in the future, installd will send back the results without the framework ever sending a command asking for them.

This diagram shows how TouchWiz 4.4 works:

Framework installd
--------- --------
| -- Start dexopt --------------> |
| <----- Receive acknolegement -- |
| -- Start dexopt --------------> |
| <----- Receive acknolegement -- |
| ............................... |
| ............................... |
| <------------ Receive result -- |
| <------------ Receive result -- |
| ............................... |

Why does this cause the boot to hang? Well, app sharing is implemented by using mbtool's 'appsync' tool, which proxies the connection between the Android framework and installd. The proxying occurs even if app sharing is disabled in order to simplify the implementation. It is designed to use AOSP's installd protocol, so appsync does not read the async replies from installd. Eventually, the replies fill up the socket's internal buffer and installd hangs until the replies are read. Also, since appsync does not read the async replies, the Android framework never knows if the dexopt processes finish, thus hanging at the boot animation. This is why a hard reboot after being patient for a few minutes would have worked around the issue. On the next boot, TouchWiz would know that the dalvik-cache has been created so it does not need to redo the dexopt process.

This diagram depicts why the issue was occuring:

Framework appsync installd
--------- ------- --------
| -- Start dexopt --------------> | --------------------> |
| <----- Receive acknolegement -- | <-------------------- |
| -- Start dexopt --------------> | --------------------> |
| <----- Receive acknolegement -- | <-------------------- |
| ............................... | ..................... |
| ............................... | ..................... |
| <------- (Nothing forwarded) -- | <-- Receive result -- |
| <--------(Nothing forwarded) -- | <-- Receive result -- |
| ............................... | ..................... |

The fix (https://github.com/chenxiaolong/DualBootPatcher/commit/5f809b239c8d1eca323473030f7c0dae7c8fde4c) was to also listen to messages from installd in addition to messages from the framework. The messages originating from installd are directly forwarded to the framework without any additional processing.