Fix the scope targets no filter can reveal and the routes that lead nowhere - #876
Merged
Conversation
…owhere The system server is offered as a synthetic row rather than an installed package, so no filter can lead a reader back to it, yet it was subject to the system-apps filter and a module whose declared scope is the framework showed an empty list. Exempt the framework alone, and only when the module asks for it. The empty-scope dialog's dismiss action closed it and returned the reader to the page they were trying to leave, where back raised it again; the only exit was to disable the module. Make that button leave, and offer the module's own recommendation as the primary action where it declares one. Legacy modules name the framework "android" and the android package "system"; modern modules and the daemon use the reverse. The store normalised the installed scope but not the catalogue's, so one module could name one target two ways in adjacent lines. Move the transform into one function both readings pass through. Module-update notifications are always enqueued for user 0 but carried the user whose PACKAGE_REPLACED raised them, so for a module installed in a private space as well as the main user the surviving notice pointed into a locked profile. Prefer user 0 when the module is installed there.
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.
Four defects in and around the module scope editor. They share a premise the code had drifted from: a module's scope is device-global, and the editor's filters, its user id and its vocabulary decide only what is offered, never what is configured. Wherever that was forgotten, the interface either hid the sole route to a target or sent the reader somewhere they could not act.
The system server is offered as a synthetic row rather than an installed package, so no filter can lead a reader back to it and nothing suggests it exists — yet it was subject to the system-apps filter, which is off by default, and a module whose declared scope is the framework therefore presented an empty list. The exemption added here is deliberately narrow: the framework alone, and only when the module has asked for it. A general rule exempting everything a module recommends was considered and rejected, since a module naming dozens of system packages would leave the filter switch controlling nothing on exactly the lists that most need thinning; readers wanting that view already have What the module asks for, which overrides all three filters.
Leaving the editor with an empty scope raised a dialog whose dismiss action closed it and returned the reader to the page they were trying to leave, where the back gesture raised it again — the only exit being to disable the module. That button now does what its label says, and where the module declares a scope the primary action becomes Use what the module asks for rather than an offer to discard an answer already in hand.
Legacy modules name the framework
androidand theandroidpackagesystem; modern modules and the daemon use the reverse. The store normalised the installed scope on its way out of the APK but not the catalogue's, so one module could name one target two ways in adjacent lines. That transform now lives in a single function through which both readings pass. It is not applied to a module that is absent, since nothing then identifies which vocabulary the entry belongs to.Finally, module-update notifications are always enqueued for user 0 but carried the user whose
PACKAGE_REPLACEDraised them. A module installed in both the main user and a private space raised two, and because the tag is the package name alone the survivor pointed into a profile that is usually locked; the editor then listed that profile's apps — none — while blaming a filter nobody had set. The link now prefers user 0 when the module is installed there, which costs nothing, as the id selects candidate apps rather than a configuration.Fixes #872