Screenshot Detection and Support Overlays for Better In-App Feedback

When users encounter issues in an app, taking a screenshot is often one of their first reactions. It may simply mean they want to save information, but it may also indicate a broken layout, confusing content, an unclear state, or a stuck workflow. Traditional feedback entry points are usually hidden in settings pages, order/history pages, or support centers. At the moment users actually hit a problem, they may not know where to report it, and they may not want to describe a complex context from scratch.

Screenshot feedback lowers the cost of explaining a problem: the user has already captured the scene. The client can supplement that with page identifiers, device information, network status, and a safe summary of recent actions, then guide the user into the support or feedback flow. This must be done with restraint. A screenshot does not always mean the user wants help, and showing a pop-up after every screenshot quickly becomes disruptive.

Our project already has the foundation for this pipeline: common contains screenshot detection capabilities, and biz_component/support contains components for support entry points, screenshot-specific support, and overlay management. BaseBizActivity serves as the base class for business Activities, giving us access to page state, automatic refresh behavior, and lifecycle events. Screenshot feedback is not just a temporary MediaStore listener on one page; it is a pipeline from “screenshot signal” to “current page context” to “support overlay.”

Detection: From Media Changes to Screenshot Judgment

Detecting screenshots on Android is typically achieved by listening to media library changes. When the system takes a screenshot, it writes an image media record. The application can observe changes to the media URI using a ContentObserver and then determine if it’s a screenshot based on file name, time, size, path characteristics, etc. Since screenshot file naming varies greatly across different manufacturers and languages, the strategy should allow for detection failure rather than introducing high false positives by trying to cover every scenario:

class ScreenshotDetector(private val clock: Clock) {
    fun isScreenshot(change: MediaChange): Boolean {
        val recent = clock.nowMillis() - change.createdAtMillis < 3_000
        val nameLooksLikeScreenshot =
            change.displayName?.contains("screenshot", ignoreCase = true) == true ||
            change.displayName?.contains("screen", ignoreCase = true) == true
        val pathLooksLikeScreenshot =
            change.relativePath?.contains("screenshot", ignoreCase = true) == true
        val sizeLooksLikeScreen = ScreenSizeMatcher.matches(
            width = change.width, height = change.height
        )
        return recent && sizeLooksLikeScreen &&
            (nameLooksLikeScreenshot || pathLooksLikeScreenshot)
    }
}

Strategy Layer: More Important Than Detection

Application-level listeners only generate events; they do not directly hold an Activity. The strategy layer is responsible for deciding whether to trigger the flow based on the current page, cooldown periods, privacy rules, and remote feature flags:

class FeedbackPolicy(
    private val cooldown: CooldownStore,
    private val remoteSwitch: RemoteSwitch
) {
    fun shouldShow(context: FeedbackContext): Boolean {
        if (!remoteSwitch.screenshotFeedbackEnabled) return false
        if (!context.appInForeground) return false
        if (!context.pageAllowsFeedback) return false
        if (context.pageContainsSensitiveInput) return false
        if (cooldown.inCooldown("screenshot_feedback")) return false
        return true
    }
}

Sensitive pages are disabled by default: login, critical workflows, identity verification, private chat content, address forms, and banking card-related pages are unsuitable for automatically popping up a feedback overlay. Even if an entry point is displayed, it should not automatically include a screenshot.

Coordinator: Connecting Detection and Display

The coordinator is responsible for chaining system events $\rightarrow$ policy judgment $\rightarrow$ overlay display, while ensuring lifecycle safety:

class ScreenshotFeedbackCoordinator(
    private val detector: ScreenshotDetector,
    private val policy: FeedbackPolicy,
    private val visiblePageProvider: VisiblePageProvider,
    private val overlayController: FeedbackOverlayController,
    private val reporter: FeedbackReporter
) {
    fun onMediaChanged(change: MediaChange) {
        if (!detector.isScreenshot(change)) return

        val page = visiblePageProvider.currentPage() ?: return
        val context = page.feedbackContext()

        if (!policy.shouldShow(context)) {
            reporter.reportSuppressed(context.pageName)
            return
        }

        overlayController.show(
            page = page,
            model = FeedbackOverlayModel(
                title = "Need help?",
                actionText = "Contact Support",
                context = context.toSafePayload()
            )
        )
        reporter.reportShown(context.pageName)
    }
}

The overlay display must be restrained—a lightweight bottom bar or small floating entry point with concise text and a close button. Do not force navigation, do not obscure critical buttons, and do not let the user think the screenshot was automatically uploaded.

Context Sanitization and Feedback Pipeline

Page context must be proactively sanitized, avoiding the collection of sensitive data such as input field contents, authentication information, full URLs, or precise locations:

data class FeedbackContext(
    val pageName: String,
    val pageAllowsFeedback: Boolean,
    val pageContainsSensitiveInput: Boolean,
    val appInForeground: Boolean,
    val lastSafeErrorCode: String?,
    val safeOperationName: String?
) {
    fun toSafePayload(): FeedbackPayload {
        return FeedbackPayload(
            pageName = pageName,
            errorCode = lastSafeErrorCode,
            operation = safeOperationName
        )
    }
}

When entering the support flow, the screenshot must be attached only after user confirmation:

class FeedbackNavigator(
    private val router: Router,
    private val consentDialog: ConsentDialog
) {
    fun openCustomerService(payload: FeedbackPayload, screenshot: ScreenshotRef?) {
        consentDialog.ask(
            message = "Attach the recent screenshot to help locate the issue?",
            onConfirm = {
                router.openFeedbackCenter(
                    payload = payload,
                    attachment = screenshot?.safeToken()
                )
            },
            onCancel = {
                router.openFeedbackCenter(payload = payload, attachment = null)
            }
        )
    }
}

Here, safeToken represents a temporary attachment reference generated internally by the client; it should not be a publicly accessible business URL, nor should it contain authentication parameters.

Key Constraints in Implementation

Set cooldown periods and session limits. For example, show it only once per session, do not repeat it on the same page within a short time frame, and do not prompt again on the same day after the user manually dismisses it. A screenshot is a user-initiated action, but the overlay is still a form of interruption.

The feedback pipeline must be able to degrade gracefully. If the support system is unavailable, the overlay should be hidden or redirect to a local feedback page; if attachment upload fails, the user should still be allowed to submit text questions; and in case of network errors, a retry state should be presented.

Data reporting must focus on the complete funnel. The number of detections, policy interceptions, overlay displays, clicks, user confirmations of attachments, successful feedback submissions, and support resolution rates are all worth observing. Simply looking at display volume is meaningless; the key is whether it reduces user churn and repeated communication costs.

Support entry points must carry explainable context. Support staff should see readable information—such as page name, time of issue, the type of feedback the user selected, whether an attachment was included, and the last safe error code—not a string of technical fields. Technical fields can be used for debugging, but internal enums should not be exposed directly to the user or frontline support.

Screenshot feedback is valuable because it catches the moment when the user is closest to explaining the problem. But it must be built on user respect and privacy protection. Detection is only the first step; the experience depends on policy filtering, restrained overlay behavior, context sanitization, and a closed support loop. A good implementation should feel like “help is available at the right moment,” not “the app is watching my photo album.” The goal is not more pop-ups; it is easier help for users and feedback that the team can locate, reproduce, and follow up on.