[JingMatrix]

getInstalledPackagesFromAllUsers is a union over users: it asks system_server for each user's packages and adds them to a running list. A union cannot distinguish a term that is genuinely empty from one that failed — both arrive as no rows, both shrink the total. v2.0 declared PackageService.getInstalledPackagesFromAllUsers throws RemoteException and propagated; the Kotlin refactor's swallow is the regression, and on a device with a work profile one lost term is one profile the reader is told does not exist.

What changes:

• The enumeration fails rather than lose a term. The reflection answers null for a query that did not happen, which the caller refuses instead of flattening into emptyList(). The user list is refused the same way, since getRealUsers turns a null binder or any failure of IUserManager.getUsers into an empty list, and no device has no users — user 0 always exists. ConfigCache.rebuild already refuses an empty user list for the same reason; this is the call the manager builds every list from.

• A failed enumeration says so. It drew "No modules installed." before, which is the same claim about an absent answer in the one place a person reads it. daemonAvailable comes from the user list and cannot speak for the enumeration, so the scan reports its own failure and the empty state names which of the two happened. The module-detection cache is left alone on that path: flush keeps only the keys whose package is in the set it is handed, so flushing the empty set would write an empty cache and make the next scan that does succeed reopen every APK on the device.

• The scan becomes a shared job, like the app list. discover() called the daemon directly rather than through the job f93a416 gave AppRepository, and observePackageChanges merges the platform's broadcast with the daemon's re-broadcast, so one install started two full enumerations and a device whose packages churn kept dozens alive at once. Each pulls every package with its metadata, per user, as a chunked ParceledListSlice, against a binder heap that is a fixed megabyte — 409 binder_alloc_buf ... failed, no address space in one report, 687 buffers outstanding, answered to the manager as DeadObjectException.

• Pull-to-refresh and the reload after an uninstall ask past that cache. It is dropped by nothing but a package broadcast, so a pull would otherwise hand back the list it was pulled to replace — on a device whose daemon was down when the module arrived, the one gesture that could have found it — and a post-uninstall reload would redraw what it had just removed. A forced read still joins a live enumeration rather than racing a second one against it.

• A package can be put into a user that does not hold it, from the long-press sheet. Scope is filtered to the module's own user, so a module a profile lacks could never be scoped there, and the manager runs in one user — nothing in the product could put a module into another, which left a profile with no modules unable to get its first. An app earns the row for the opposite reason: a module goes into a profile so it can be scoped there, an app so a module already in that profile can reach it. installExistingPackageAsUser moves no APK; it flips the install state for that user, and the package keeps its version, its signature and its uid derivation.

• The users offered are the device's, not the ones on screen. getPackageUsers answers which users hold one package, by the same isPackageAvailable probe the enumeration filters each user's rows by, so a user it reports and a user whose apps the manager draws mean the same thing by "holds" — and one transaction per user, since enumerating every package of every user to answer a question about one package is what exhausts the heap above. The module list's tabs would have answered for a module, but only for the users it draws: a profile holding no modules has no tab, and that is exactly the profile worth offering. The sheet subtracts the holders from getUsers rather than inverting them, because a daemon that cannot reach the user service answers empty to both, and an empty holder set inverted against a user list of the manager's own would offer every user on the device.

• include new apps is keyed by user. It was a column on modules, a table keyed by package name alone, so one module carried one flag for the whole device: turning it on from a work profile's scope screen turned it on for the owner too, and the install handler read it without a user at all, handing each new app to every auto-including module and writing it under whichever user it arrived in. It is a table now, auto_include (mid, user_id), where a row's existence is the whole value; keyed by mid so that uninstalling a module takes these rows with it as it takes its scope. The old column stays, dead and selected by nothing, because SQLite gained DROP COLUMN in 3.35 and this supports API 27.

• Database v5 migrates that flag. Every user is what it meant in effect, so one row per user preserves it, and the users come from scope — the only table that names any — unioned with user 0. Not from IUserManager: a migration runs wherever the database is first opened, which is early and is not a place to need a system service, and one that silently found no users would read as a setting nobody had ever made. A user that neither holds scope nor is 0 loses it, and a user created afterwards never had it; both are what the switch now means rather than a gap in it.

• The long-press sheet opens at the stop it settles on. Material offers the PartiallyExpanded anchor only to a sheet taller than half its container and places it at exactly half; three rows here wait on a binder call, so the sheet was first measured without them, landed short of that line, retargeted to Expanded, and snapped back a third of a second later once the rows arrived. Measured at 1131px without them and 1483 with, against a stop at 1200. A floor at that stop makes the first target the one it keeps.

• The sheet's actions can be put in the reader's order. A toggle in the header turns the rows into a list with a pair of arrows each, stored by id per kind of package so an action added or retired later leaves the rest where they are. Arrows rather than the drag PanelBar uses for the navigation panels: a drag works there because the bar does not move under it, and fails here because the sheet does — it takes the pointer back and ends the reorder as a cancel.

• The user picker shows each user's own photo. IUserManager.getUserIcon opens the file the daemon can reach and the manager cannot; most users have never been given one, so the fallback — a circle carrying the first letter, tinted from the user id — is the ordinary case rather than the error case.

• PROTOCOL_VERSION goes to 3. Transaction ids follow declaration order, and two changes here moved them: installExistingPackageAsUser, declared in the middle of the interface, and then getPackageUsers and getUserIcon after it. Nothing else makes such a shift visible to a peer — the descriptor still matches across it, so two builds that disagree about what each id means still bind, and then each call lands on the wrong method. That is the failure the handshake replaced hand-written ids to prevent. The daemon reuse policy makes it the ordinary upgrade path rather than a corner: one daemon is started per boot by service.sh, a module update replaces files on disk and starts nothing, a replayed service.sh finds the lockfile held and exits, and softReboot restarts zygote rather than the daemon — so from installing a module until the next real boot, the manager APK on disk is the new build and the daemon answering it is the old one.

• The empty state can be pulled. It said "pull down to try again" from a branch that returns before the PullToRefreshBox, so there was nothing to pull and no other way to retry. It is wrapped in one now, holding a single full-height item in a lazy list — a pull is seen through nested scroll, and a static box dispatches nothing to see.

• Smaller, in passing: the flag conversion moves out of the per-user loop it could not vary inside, and moduleIdOf closes the statement it compiles.

• For working on it: restartManager<Variant> installs the manager alone and restarts it in about three seconds. Every root provider's install stages into /data/adb/modules_update and leaves the next boot to promote it, while the daemon reads the manager APK beside its own in /data/adb/modules — so a one-line Compose change used to cost a reboot.

Two things #953 asks for that this does not do:

• A profile holding no modules still has no tab of its own. discover() drops a user with nothing in it on purpose — a private space that has never had a module would otherwise add a second tab to a screen with no choice on it — so "show every user" holds only for users that hold modules. Such a profile is offered as an install target whether or not it has a tab, and gets one as soon as it holds a module, which is what the action above exists for.

• enabled is still one flag per package for the whole device. It sits on the same row auto_include has just left, so switching a module off in one user's tab switches it off in every user. Keying it by user is a larger change than this: unlike include new apps, which only decides what a future install does, enabled is read on every process start and on every cache rebuild.

One shortcoming of its own, which #953 does not ask about:

• Between a module update and the next boot, the manager says only "Version mismatch". That is the handshake above refusing a new manager against the daemon still running from the last boot — correct, and unavoidable while the daemon is reused — but two words do not say that a reboot is what finishes the update, nor which of the two ends is the stale one, and the manager knows both: it compares its own PROTOCOL_VERSION against the number the daemon answered.

Closes #953.