ADFA-4842: module management stops the server + blocks the whole UI#255
Draft
luisguzman-adfa wants to merge 1 commit into
Draft
ADFA-4842: module management stops the server + blocks the whole UI#255luisguzman-adfa wants to merge 1 commit into
luisguzman-adfa wants to merge 1 commit into
Conversation
…no live-rootfs corruption) Installing a module runs ./runrole in an app-side proot that modifies system packages/config. On a live system that collided with the running server over the shared rootfs (corruption risk). Content ops avoid a 2nd proot via the in-server engine; a runrole can't, so instead we quiesce the server around it. - InstallService: before the module queue, stop the server's services (pdsm stop, idempotent) so no runrole ever runs alongside a live server writing the same DBs/config. The server is brought back after the queue. - LibraryActivity: while the queue runs, block the ENTIRE library UI behind the full-screen (match_parent, clickable) boot gate — every tab (Library, Connect, Clone, Settings) and the nav bar, not just the cards — showing 'Modules are being installed. Please wait.' + the current module. When the queue finishes, drop the block and restart the server (guarded by canStartServer, so never a 2nd proot). Reuses existing strings (server_shutting_down, install_busy_modules). Needs on-device verification. Note: if the queue runs entirely while LibraryActivity is destroyed, the restart falls back to the ADFA-4837 'couldn't start - tap to retry' affordance.
luisguzman-adfa
marked this pull request as draft
July 24, 2026 03:37
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Installing a module runs
./runrolein an app-side proot that modifies system packages/config. On a live system that collides with the running server over the shared rootfs (data-corruption risk). Content ops avoid a 2nd proot via the in-server engine (ADFA-4838); a runrole can't, so instead we quiesce the server around it.InstallService: before the module queue, stop the server's services (pdsm stop, idempotent) so no runrole runs alongside a live server writing the same DBs/config. The server is brought back after the queue.LibraryActivity: while the queue runs, block the entire library UI behind the full-screen (match_parent,clickable) boot gate — every tab (Library, Connect, Clone, Settings) and the nav bar, not just the cards — showing "Modules are being installed. Please wait." + the current module. On finish, drop the block and restart the server (guarded bycanStartServer, so never a 2nd proot).Reuses existing strings (
server_shutting_down,install_busy_modules). Ships via APK (no rootfs change). Needs on-device verification.Caveat: if the queue runs entirely while
LibraryActivityis destroyed, the restart falls back to the ADFA-4837 "couldn't start — tap to retry" affordance (recoverable, not broken).