feat(permissions): guide Xiaomi/HyperOS users to enable lock-screen calls (WT-1349)#1411
Draft
SERDUN wants to merge 4 commits into
Draft
feat(permissions): guide Xiaomi/HyperOS users to enable lock-screen calls (WT-1349)#1411SERDUN wants to merge 4 commits into
SERDUN wants to merge 4 commits into
Conversation
…alls On Xiaomi/HyperOS the incoming-call screen cannot cover the lock screen unless the OEM 'display pop-up windows while running in background' capability is enabled, which the standard permissions do not cover. Drive the manufacturer tip from the new callkeep background-activity-start status: surface it only while the capability is missing (so it clears once the user enables it and returns), and point the action button at the OEM 'Other permissions' editor via the new deep link. Update Xiaomi instructions accordingly (en/uk/it). WT-1349
SERDUN
commented
Jun 19, 2026
SERDUN
commented
Jun 19, 2026
SERDUN
commented
Jun 19, 2026
checkPermissions() runs fire-and-forget on every resume and emits after several awaits (now including a platform-channel call). Without an isClosed check the late emit throws 'Cannot emit new states after calling close' when the screen is left mid-await. Add the guard, matching initiatePermissionFlow. WT-1349
_checkManufacturer matched only the literal 'xiaomi', so Redmi/Poco devices (which report their own manufacturer string) never showed the tip even though the native layer reports the OEM capability denied. Match xiaomi/redmi/poco by substring, aligning with PermissionsHelper.isXiaomiFamily. WT-1349
…ms unreachable backgroundActivityStart is surfaced via the manufacturer tip, not the special-permission pipeline (it is not in _specialPermissions). Document the otherwise-misleading switch arms in SpecialPermission, SpecialPermissionTips and toSpecialPermissionsSetting so they are not mistaken for a second live entry point. WT-1349
SERDUN
added
help wanted
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.
Problem
On Xiaomi/HyperOS the incoming-call screen does not cover the lock screen, even with all standard permissions granted. The blocker is the OEM capability "Display pop-up windows while running in background" (
OP_BACKGROUND_START_ACTIVITY), which is separate from the user-facing "Show on lock screen" toggle and has no public API. See WT-1349.Change
Drives the existing manufacturer tip from the new callkeep
backgroundActivityStartstatus:appPermissions.backgroundActivityStartStatus()), so it clears itself once the user enables it and returns to the app (re-checked onresumed).openBackgroundActivityStartSettings()instead of generic app settings.Non-blocking: this uses the dismissible manufacturer-tip path, so it never traps onboarding. No effect on non-Xiaomi devices.
Depends on webtrit_callkeep PR #337 (consumed via the local path dependency on develop).
WT-1349