[JingMatrix]

A module scoped to the system framework through the CLI is never loaded into it, and says nothing anywhere. #1061 is that, configured entirely through vector-cli on a device with no manager: cli scope ls answers android, com.google.android.gms and the module's own package, the framework bootstraps completely inside system_server — injection, PreloadedDex, full LSPlant init, every framework hook, the daemon channel — and then module loading for the system package never starts. No error, no exception, no skip entry.

getModulesForSystemServer is the whole of where that process's module set comes from, by way of getAllModules sending uid 1000 and process system there rather than to the scope map, and it reads systemServerModuleRows — app_pkg_name = 'system', and nothing else, because it answers before any package manager exists to expand a package name with. A row spelled android is therefore invisible to it, and the reporter's correct observation that nothing was skipped is for a different reason than they took it for: SystemServerService.attachProcess does not consult the scope at all, so Process channel attached for system and no Skipped system/1000 is what both a working and an unconfigured system server look like.

Two things let the row be written and then kept quiet about it.

The CLI wrote whatever it was handed. handleScope split a target on / and passed the halves to setModuleScope, which normalises the user id for system and has never had an opinion about the name. A typo, a package that was uninstalled, a package name from another device: all accepted, all listed back by scope ls, all reaching nothing. add and set now refuse a target the daemon can see is not there, by name, through the predicate getInstalledPackagesFromAllUsers filters the manager's own list by — so what the editor offers and what a write may name are one thing, hidden packages included. The predicate has a third answer for having no package manager to ask, since this socket is listening before main has waited for one and a question that cannot be asked is not a no. rm deliberately still takes anything, because the rows already written this way have to stay removable.

The rebuild built an entry for it that nothing queries. android resolves, so the row went down the ordinary path, and fetchProcesses answers system for that package among others — the expansion added a system/1000 entry, which no reader ever looks up, since getAllModules sends that process to the database instead. The module held the framework in the configuration and was never in it. That entry goes, and the rebuild logs the package the row named and the word that would have worked. com.android.providers.settings is the same shape and gets the same line, correctly: its provider does run in the system server, and system is how a module reaches it.

Which leaves the vocabulary, which is the actual trap. system is the system server and android is the ordinary framework package — ScopeViewModel synthesises the first and shows it as system_server, swapLegacyFrameworkNames turns a legacy module's reversed spelling around, and the CLI said neither. It cannot refuse android: that is a legitimate row, reaching android:ui. So scope --help and the three target-taking commands spell out which word means which.

Also here: the scope request path had its own inline copy of the "is this target there" test, which is now the one predicate beside the rebuild that depends on it; and the three commands share one target parse instead of spelling pkg/user_id out apiece.

Left alone: that system/1000 can be in the scope map at all. Nothing reads it, so the entry is dead rather than wrong, and removing the special case in getAllModules would mean teaching the system-server path to answer from a cache that does not exist when it is asked.

Not tested on a device. The refusal and the help text are straightforward; the rebuild's warning is on a path I can only reach by configuring a module the way #1061 did.

[JingMatrix]

Basically, AI generated PRs are of low quality.

Sometimes I wish AI could replace me, sigh...