IGPAPI
    Preparing search index...

    Variable AccountRecoverySuccessLocationPermissionScreenConst

    AccountRecoverySuccessLocationPermissionScreen: ScreenDefinition<
        "AccountRecoverySuccessLocationPermission",
        "screen",
        undefined,
        {},
        Record<never, never>,
        InvalidSkipOrdinalsError | ScreenEnterNavigationError,
        MobileNavigation,
        {
            close: (
                self: ScreenHandle,
                _state: never,
            ) => () => Effect<
                ScreenFrameHandle
                | undefined,

                    | ScreenEnterConcurrentError
                    | ScreenNotOnTopError
                    | ScreenNotNavigableError
                    | ScreenRootBackError,
                MobileNavigation
                | ScreenStack,
            >;
        },
        Record<never, never>,
        never,
    > = ...

    The location-permission prompt the Android 451 build shows over the feed at the end of a launch that follows a successful account recovery (the 451 launch flow).

    The person sees a consent dialog: "Open your location settings to allow «Instagram» access to your location", the hint "In your device settings tap «Permissions» and tap «Location» to turn it on.", and the buttons "Cancel" and "Open settings" — the screen's own answer names it a location_foreground / precise request and logs its events under the product NDX. The app opens it from the login-interstitial QuickPromotion chain: the promotion carries the account_recovery_success client filter, so the 451 password login carries the same promotion and shows no such screen.

    The Instagram identity is the recorded Bloks app id com.bloks.www.bloks.ig.ndx.ls.entry.screen: SCREEN_CATALOG keeps it as a Bloks screen (host: 'screen'), so Android renders <appId>:<appId> and iOS names the same identity; the public name says what the screen is. The launch fetches the screen before showing it (postAccountRecoverySuccessLocationPermissionScreen, the QuickPromotion action's qp_id/qp_nux_id in its server_params); the screen's enter sends nothing itself. It holds no data, and no recording shows the app's later dismissal, so the close edge is the universal back (navigation only — a recording of "enter on 451, close this screen, act in the feed" decides what the app sends there). Its screenshot is pending a recording that shows the prompt.