Why Android's scrolling screenshot is greyed out in the app you actually need it in

If you have tried to take a scrolling screenshot on Android, you have probably had this happen: it works in Chrome, it works in Settings, and then you open the one app where you actually need it and the Capture more button is not there.

That is not a bug in your phone. It is a consequence of how the feature is implemented, and it is worth understanding because it tells you exactly when to expect it to fail.

Try the built-in one first

Genuinely - if this works for your case, stop here.

• Samsung: take a normal screenshot, then tap Capture more in the toolbar that appears. It has to be enabled in Settings > Advanced features > Screenshots and screen recorder.
• Xiaomi / MIUI: screenshot, tap the thumbnail, then Scroll.
• OnePlus / OxygenOS: screenshot, then the expand arrow on the preview.
• Chrome: screenshot, then Capture full page in the preview - this one is Chrome's own and works on any Android.
• Android 12+ stock: screenshot, then Capture more if it appears.

For a web page in Chrome, the built-in path is usually the better answer. It captures the page as the browser knows it, not as pixels.

Why it disappears

The platform feature is not a screen recorder. It asks the app's own view hierarchy to scroll and render more of itself, which means the app has to implement the right hooks - a ScrollCaptureCallback on Android 12+, or on Samsung the view has to be one MIUI/One UI knows how to drive.

Which apps do not? Anything drawing its own surface. Feeds built on custom rendering, most chat apps, anything backed by a SurfaceView or TextureView, most Flutter and React Native screens, WebViews inside apps, and anything the manufacturer has not specifically wired up.

So the rule of thumb is: the more custom the UI, the less likely you get the button. Which is exactly backwards from where people want it - nobody needs a scrolling screenshot of the Settings app.

What the alternative approach costs

The other way is to record the screen while you scroll and stitch the frames back into one image. That works in any app, because it operates on pixels and never asks the app for anything.

It also inherits every problem of doing it from the outside:

• You have to scroll yourself. An app could scroll for you, but only by holding an AccessibilityService - and that same permission lets it read the content of every screen you open. That is a large thing to hand over for a screenshot tool.
• A human thumb is not a machine. It accelerates, overshoots, and drifts a pixel or two while it is supposed to be still. Every one of those breaks a different assumption in the stitching, and getting them right is most of the work.
• Moving content is genuinely hard. A playing video keeps moving while you scroll past it, so its area gets read a few rows at a time from different moments.
• Screenshot-blocked apps still come out black. Banking apps and DRM video are blocked by Android at the compositor. No approach on either side gets around that, and you should be suspicious of one that claims to.

Disclosure

I build one of these: LongShot, free on Google Play.

The specific trade-off it makes is the permission one. It uses MediaProjection - the ordinary screen-share API - and never asks for accessibility access, so it cannot scroll for you. In exchange it has no INTERNET permission at all, and that is checkable rather than promised: it is stripped from the merged manifest, so the process cannot open a socket. Run aapt dump permissions on the APK and you will see four permissions and no INTERNET.

That constraint decides the rest of the design. Text recognition (copy text out of a capture, or auto-cover emails, phone numbers, card numbers and IBANs before sharing) runs on a model bundled in the app, because there is no service it could call.

Where it falls short, from the app's own About screen:

• Pause any playing video before you capture. Moving content can come out stitched from several moments. Measured and located; not yet fixed.
• Text recognition is Latin script only. Arabic and other non-Latin text is not detected, so redaction there has to be done by hand with the blur tool.
• A hard fling can outrun the capture. Steady scrolling is more reliable than fast.
• Screenshot-blocked apps come out black. As above - that is Android.

If the built-in button is there and works, use it. It is faster and it is lossless. The stitching approach is for the case where the button is missing, which - if you have read this far - is probably why you are here.