DEV Community: Codnet Software Company

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

Codnet Software Company — Sat, 05 Sep 2026 00:51:25 +0000

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.

Your test harness can silently not be testing the thing you think it is

Codnet Software Company — Sat, 05 Sep 2026 00:34:27 +0000

I spent a week fixing a stitching bug in an Android app, and the single most expensive thing was not the algorithm. It was that my offline test harness was quietly not exercising the code I was changing.

Here is the shape of it, because I doubt it is rare.

The setup

The app records a scroll and joins the frames into one tall image. To iterate on that without re-shooting captures by hand, debug builds write a journal of every frame, and a test replays the journal through the same engine offline. Same input, same code, repeatable.

That harness is the whole basis for every claim I make about the engine.

Three ways it lied

1. It never called the guard it was grading.

The engine has a pass that rewrites a video area from one frame so it does not come out as a collage of moments. The call existed in one test function and not in the one I was using. So every measurement of video tearing I had taken was of the engine with that guard switched off.

That is not a small discrepancy. It meant a change to that guard could not move the number in either direction, which is exactly what happened: I made a fix, measured no effect, and concluded the fix was wrong. It was not tested at all.

2. One missing callback made recovery impossible.

Production wires three callbacks into the engine. The replay wired two. The missing one reports how far down the page the canvas currently reaches - and a guard deep in the relock path reads it. With it null, that guard can never be true, so a chain that loses its place in the replay can never recover.

Same 908-frame journal:

                 before   after   real device
output rows       2464    13305      13720
writes               7       99          -

One line. The harness had been reproducing a crippled engine and I had been reading its output as production behaviour.

3. I pasted a call one nesting level too deep.

After fixing the above I added the guard call by line number and it landed inside if (repairs <= 40) { ... }, itself inside another conditional. It ran only when an unrelated repair had just succeeded - which never happens on the journal I was testing. The counter read zero, and I published the conclusion 'this guard never fires'. It fires four times.

Why none of these looked like failures

A broken measurement does not raise an error. It returns a number, and the number is usually plausible.

Worse, the failure mode is biased. An empty output reads as 'nothing found'. A zero counter reads as 'no effect'. A skipped task reads as 'no change since last time'. All three are indistinguishable from the most common real result, which is that your change did nothing.

In one week I hit six of these. A grep pattern that missed indented output. A build task skipped as up-to-date, so I compared against a run that never happened. A template calibrated on one recording and applied to another, matching 77% of the page and reporting no difference. A -D flag the build never forwarded to the test JVM. Launching the wrong package on the phone, because the debug build installs alongside the store build under a different application id. And the nesting mistake above.

Three of them produced a diagnosis I acted on and had to undo.

What I do now

Prove the instrument can move before you trust it. Feed it a case where it MUST report non-zero. If it cannot produce a positive, its negative is worthless.

This is what finally caught the harness problem. My tearing metric said all three recordings were clean. Instead of accepting it I checked whether it could report a tear at all - and the check failed, which is how I found the guard was never being called.

Check the wiring matches production, not just that the test passes. A green suite proves the code compiles and the assertions hold. It says nothing about whether the code path you care about was reached.

An empty output is a question, not an answer. Every time this bit me, the tell was output that was emptier than it should have been - and I read it as a result instead of asking whether the tool had run.

The other half

The same week taught me a related one: an optimisation measured only where the system already works tells you nothing.

I sampled every second pixel in a hot loop. On the reference recording the worst frame halved and detection was unaffected, so I shipped it. Re-run on the recording where detection was already weak, it fired twice as many repairs while landing fewer rows, and the worst frame nearly tripled. The gain was specific to one recording; the cost was general.

Reverted, with the numbers written into the source above the function so the next person to have that idea finds the measurement instead of repeating the week.

The app is LongShot - free, no ads, and no INTERNET permission, which is checkable rather than promised: it is stripped from the merged manifest, so the process cannot open a socket.

Known limitation, stated in the app itself: pause any playing video before capturing. Moving content is read a few rows at a time as you scroll past it, so it can come out stitched from several moments. That one is measured and located, and not yet fixed.

Why capturing a long screenshot on Android is harder than it looks

Codnet Software Company — Sat, 29 Aug 2026 13:55:21 +0000

Every phone can screenshot what is on the screen. None of them, out of the box, can screenshot what is below it — the rest of the chat, the rest of the article, the rest of the settings page you are trying to send to someone. You take five overlapping screenshots and apologise for the seams.

I spent a while building an app that does the whole scroll in one image — LongShot — and most of that time went not into the feature people ask for but into the failure modes nobody sees. Here is what actually makes this hard, and how the app handles each part. No framework does this for you; you assemble it out of parts that were built for other jobs.

There is no "capture the scroll" API

The first instinct is to look for a system call that returns a tall bitmap. There isn't one. What Android gives a normal app is MediaProjection — the same API a screen recorder uses. You get frames of what is currently visible, at the moment it is visible, and nothing else.

So a scrolling screenshot is not a capture. It is a reconstruction: record the screen while the user scrolls, then stitch the frames back into the single tall image they would have formed if the screen were long enough to hold them.

The deliberate cost of using MediaProjection instead of an AccessibilityService — which can read and drive other apps — is that the app cannot scroll for you. You scroll; it records. That trade is the whole reason the app can honestly say it never reads the content of your other apps: it has no mechanism to.

The stitch is the entire problem

Say the user scrolls through a chat. You have thirty frames, each 1080×2340, overlapping by some unknown amount because a human thumb does not move at a constant speed. Stitching them means, for every new frame, answering one question: how far down has the content moved since the last frame I kept?

Get it right and the frames weld into one seamless column. Get it wrong by four pixels and you either duplicate a band of content or drop one, and the result has a visible tear or a line of text that appears twice.

The naive approach — template-match the whole frame against the previous one — falls apart the moment anything on screen moves independently of the scroll: a playing video, an animated sticker, a "typing…" indicator. Those regions match at the wrong offset and drag the whole estimate with them. The capture that looks hardest (a feed full of autoplaying video) is exactly the one a whole-frame match handles worst.

What works is consensus over rigid slices: cut each frame into horizontal strips, ask each strip independently how far it moved, and trust the offset the majority of strips agree on rather than any single region. A video playing in the middle of the screen becomes one dissenting slice outvoted by the static ones around it. The text keeps its place; the video's private motion is ignored.

Memory is the quiet killer

A full capture of a long chat is routinely 1080×18660 pixels. At 4 bytes a pixel that is ~80 MB for one bitmap — and while you are building it you are also holding the frame buffer, the display copy, and whatever the editor needs. Decode one thing carelessly and a 2 GB device is out of memory before it finishes.

Two things keep it alive:

The finished image is never held whole. It is streamed to a PNG on disk row by row, so an arbitrarily long capture saves at full resolution without ever existing as a single in-memory bitmap.
Anything that decodes a saved capture back — for a thumbnail, for text recognition — does it a region at a time with subsampling, so the cost is bounded by the tile, not by how tall the capture happens to be.

I learned the byte-vs-pixel distinction the hard way: a memory ceiling written in pixels while the actual cost is bytes will pass every test on short captures and OOM on the long ones users actually take.

The on-device extras, and one honest limit

Once the pixels are on the device and staying there, a few things follow for free — because "no network" is not a slogan here, it is enforced: the app declares no INTERNET permission at all, and both INTERNET and ACCESS_NETWORK_STATE are stripped from the merged manifest, including the copies the bundled ML Kit recogniser would otherwise pull in. The operating system refuses any socket, so nothing recognised from your screenshot can leave the device even if a library tried. You do not have to trust me on that — run aapt dump permissions on the APK.

On top of that:

Copy text lifts the words out of a capture with on-device recognition, in reading order — banded into lines, sorted within each band, paragraph breaks inferred from the gaps.
Hide personal data finds card numbers (Luhn-verified), IBANs (mod-97-verified), emails and phone numbers, and paints them out — genuinely out, not blurred, so the covered pixels are gone from the exported file rather than merely scrambled.
Text, in 13 typefaces — 7 Arabic and 6 Latin — with free rotation and resizing, for annotating over the shot.
Crop, PDF/PNG export, share.

The honest limit: the text recognition is Latin script only. ML Kit ships no Arabic model — the artifact literally does not exist — so Arabic and other non-Latin scripts are not read. The app says so on screen rather than returning a confident empty result. If you build on ML Kit and expected Arabic, that is the thing to know going in.

If you are building something similar

Don't look for a scroll-capture API; there isn't one. Reconstruct from MediaProjection frames.
Estimate scroll offset by consensus across rigid slices, not whole-frame matching, or independently-moving content will wreck the alignment.
Budget memory in bytes, not pixels, and never hold the finished image whole.
If your privacy story is "no network," enforce it by removing the permission, not by promising — and check the merged manifest, because your dependencies vote on it too.

LongShot is free on Google Play, no ads, no accounts, no analytics: https://play.google.com/store/apps/details?id=com.codnet.longshot

Happy to go deeper on any part of the stitch in the comments — the slice-consensus stage especially has more corners than fit here.

Two features were dead in every release build for a month — and worked in every debug build

Codnet Software Company — Thu, 27 Aug 2026 10:48:42 +0000

LongShot is an Android app that stitches a scrolling screen into one long screenshot. Two of its tools run on-device text recognition: Copy text pulls the text out of a capture, and Hide personal data finds card numbers, IBANs and phone numbers and covers them.

For a month, both were dead in every published build.

Not crashed. Not slow. Dead in the quietest way available: you tapped the button, waited, and got

Couldn't read this image.

No crash dialog. Nothing in Android Vitals — the app never crashed, so there was nothing to report. The crash rate for the entire period reads –. Every user who tried the feature concluded the app couldn't handle their screenshot.

They were wrong. It could not handle any screenshot.

Why it took five rounds to find

Because it worked. Every single time I tested it.

I test on a device over ADB with installDebug. The debug variant is not minified — that is the Android default, and I had never questioned it. So five rounds of "fixed it, please try again" were five rounds of verifying a code path R8 had never touched.

The false trails I burned first, in order:

Memory. The captures are tall — 1080 × 18660 is ordinary. I assumed the recogniser was being handed a bitmap it could not allocate, and rewrote the scanner to read the image one tile at a time through BitmapRegionDecoder.

A budget in the wrong unit. While doing that I found a genuine bug: the scan budget was expressed in pixels while the cost is bytes. The code's own comment described the danger, then set the ceiling at exactly the dangerous value.

A fix that was a no-op. I set inPreferredConfig = RGB_565 to halve the memory. Logging showed decoded 1080x3404 ARGB_8888. BitmapFactory ignores the preference for images with an alpha channel. My fix changed nothing — and I only knew because I had added the log line.

A bug I introduced myself. BitmapRegionDecoder reads from its InputStream on every decodeRegion call, not only at construction. I wrapped the stream in .use { }; every tile then failed. I verified the fix on a 2340-pixel capture — the one input short enough never to be tiled, and therefore the exact input that cannot exhibit the bug.

All of that was real work. None of it was the cause.

What cracked it was a question from the person reporting the bug:

Is this about the library not being included in the app when you export it?

What R8 actually did

ML Kit does not find its components through any call R8 can see. The merged manifest names them in a <meta-data> tag, and a component runtime instantiates each one by reflection:

<meta-data
    android:name="com.google.mlkit.vision.text.internal.TextRegistrar"
    android:value="com.google.firebase.components.ComponentRegistrar" />

The library ships a consumer rule for exactly this case. Here it is, copied out of configuration.txt in my own release build:

-keep class * implements com.google.firebase.components.ComponentRegistrar

That rule keeps the class. It says nothing about the class's members — and in ProGuard/R8 that is the entire difference. -keep class X guarantees X survives shrinking. It guarantees nothing about what is inside X.

So R8 kept TextRegistrar, observed that nothing in the program ever calls its no-argument constructor — nothing does, in bytecode — and removed it. usage.txt, R8's record of what it deleted, named it in one line:

com.google.mlkit.vision.text.internal.TextRegistrar:
    public void <init>()

At runtime the component runtime asks for an instance, finds no constructor to invoke, initialisation throws, and TextRecognition.getClient() fails. My code catches it:

val recognizer = try {
    TextRecognition.getClient(TextRecognizerOptions.DEFAULT_OPTIONS)
} catch (t: Throwable) {
    Log.e(TAG, "scan: text recogniser unavailable", t)
    return Result(emptyList(), 0, 0)
}

— and the UI, having examined zero pixels, reports that it couldn't read the image. Which is true, and completely useless as a diagnosis.

The fix

One line. It is the stock rule with a member specification added:

-keep class * implements com.google.firebase.components.ComponentRegistrar { <init>(); }

You do not have to take that on faith, and neither did I. Comment the line out,
leaving the library's own rule in force, and rebuild:

$ grep '<init>' app/build/outputs/mapping/debug/usage.txt   # what R8 DELETED
com.google.mlkit.vision.text.internal.TextRegistrar:
    public void <init>()

$ grep TextRegistrar app/build/outputs/mapping/debug/seeds.txt   # what R8 KEPT
com.google.mlkit.vision.text.internal.TextRegistrar

One line in seeds.txt: the class, and nothing else. Put the rule back and
build again:

$ grep TextRegistrar app/build/outputs/mapping/release/seeds.txt
com.google.mlkit.vision.text.internal.TextRegistrar
com.google.mlkit.vision.text.internal.TextRegistrar: TextRegistrar()

Two lines: the class and its constructor. Same source, same library, same
stock rule present in both — the only variable is the member specification.

In my build that single rule covers seven registrars.

About the advice you will find instead

Search for this problem and you will be told to write:

-keep class com.google.mlkit.** { *; }

That works. It also switches off shrinking and obfuscation across the entire ML Kit surface in order to save one constructor. The narrow rule is the same fix at a fraction of the cost — and it is not ML Kit-specific. It covers any ComponentRegistrar, which is how the whole Firebase component system is discovered.

The change that actually matters

Fixing the rule fixes today's bug. It does nothing about the reason the bug lived for a month.

That defect was in the build configuration:

debug {
    // Minified like release, on purpose. The text features were broken in every
    // published build and worked in every debug build, because R8 runs only in
    // release and strips a constructor ML Kit needs by reflection. A debug variant
    // that does not run R8 cannot reproduce the one class of bug that reaches users,
    // so this one does. It costs build time; it buys the ability to test what ships.
    isMinifyEnabled = true
    proguardFiles(
        getDefaultProguardFile("proguard-android-optimize.txt"),
        "proguard-rules.pro"
    )
}

A debug variant that skips R8 cannot reproduce any R8 bug. That is not a small blind spot. Reflection-driven initialisation is exactly where release-only failures live, and it fails silently rather than loudly — no crash, no stack trace, no Vitals entry, just a feature that quietly does nothing.

Builds got slower. In exchange, the thing I test is the thing I ship.

Afterwards

On a minified build, against a 1080 × 18660 capture:

scan:     299 raw lines over 14 tiles (0 failed)
redact:   286 lines over 14 tiles (0 failed), 3 region(s), full-res
copyText: 286 lines over 14 tiles (0 failed), full-res

Zero text recogniser unavailable. 125 unit tests, 0 failures.

If you ship ML Kit, Firebase, or anything with a ComponentRegistrar

Three checks, all cheap, all on a build you have already made:

grep '<init>' app/build/outputs/mapping/release/usage.txt — anything reflection reaches whose constructor appears here is already broken in what you shipped.
grep Registrar app/build/outputs/mapping/release/seeds.txt — every registrar should appear twice: once as a class, once as a constructor. Once means the constructor is gone.
Turn on isMinifyEnabled for debug and launch the app.

The third one is the one that finds the next bug instead of this one.

LongShot is free on Google Play. It captures with MediaProjection rather than an AccessibilityService, so it cannot read or act inside other apps — the trade is that you scroll manually. It declares no INTERNET permission: INTERNET and ACCESS_NETWORK_STATE are removed from the merged manifest with tools:node="remove", including the copies ML Kit would otherwise merge in, so the operating system refuses any socket rather than the developer promising not to open one. You do not have to take my word for that one — run aapt dump permissions on the APK.

Why scrolling screenshots fall apart on video feeds

Codnet Software Company — Mon, 24 Aug 2026 16:20:57 +0000

I maintain a small Android app that stitches a scrolling screen into one long image. It worked well until people started pointing it at social feeds, and then users began reporting that captures "overlapped" around video posts.

Chasing that report taught me it was two separate defects wearing one description, and that my measurement could only see one of them.

The measurement comes first

Before changing anything I made the failure reproducible offline. Debug builds write every delivered frame's grayscale to a journal file, so a real session can be replayed against any candidate algorithm - the only honest way to compare two engines, since you can never reproduce a hand gesture twice.

Then I needed ground truth that did not come from the engine. Matching consecutive journal frames directly, with no chaining and no accumulated estimate, gives the real scroll between them, and therefore the real page position of every frame. Now every row the engine commits can be checked: canvas rows increase, so the page rows they carry must increase too. A step backwards means content already emitted was emitted again.

That audit is what let me stop guessing.

Defect one: the video captures the measurement

A playing video is not noise. Uncorrelated noise costs the same at every candidate offset, so it cannot move the argmin - I built a noise fixture first and it passed happily while the real bug sat untouched. Real video is structured and its scene moves coherently, which plants a second minimum in the offset landscape at the video's own motion.

When the video covers more of the textured pixels than the page does, every majority-of-pixels metric prefers that minimum. Rows land at the wrong page address. On a synthetic feed with a coherently panning video the error compounded at exactly the video's pan rate, every single frame.

The obvious fix is to exclude moving rows from the measurement. That fix has a trap in it.

The inversion

To know which rows are moving you compare the last two frames - but you have to compare them at some offset, and the only offset available is the last one you accepted. So the test is anchored to the answer it is supposed to be checking.

The moment that offset is wrong, the test inverts. Under the video's inflated offset the video's rows line up perfectly and are judged still, while the real page's rows do not and are judged to be the thing that moves. The exclusion mask ends up protecting the noise and discarding the evidence.

It cannot be repaired downstream either. I tried re-registering against the committed image - but that image was written by the same wrong chain, so it agrees with the error and confirms it. Measured: the trimmed cost was 73-89, flat, at every single offset. There was nothing left to appeal to.

Rigid slice consensus

What worked was removing the anchor.

Page content is a rigid body. Every horizontal slice of it moves by the same offset and reproduces the previous frame almost exactly there. Whatever refuses to fit that one offset is moving by itself: a video, a GIF, an advert, a live chart.

So: split the visible band into slices of about 128 px, score each against the offset the frame just produced, and read off which ones fit. If nothing fits at all, refuse the frame. If the winner explains almost nothing but a distant rival exists, score the rival too and let consensus - not average cost - pick between them.

This needs no previous estimate, which is the entire point. A consensus cannot invert. At worst it finds too little agreement, and that is a refusal, not a wrong answer.

Two details mattered more than the idea itself:

The consensus must never be fed back into verification. I tried it. An offset that is allowed to excuse whatever it fails to explain will certify itself, and my fuzz harness immediately started putting solid rows on the wrong page. Verification has to use evidence that is independent of the offset under test.

Excluding a slice and remembering it need different thresholds. Excluding a slice from one frame is cheap and reversible. Recording a page region as animated steers every later frame and survives freezes, so it needs roughly double the evidence - otherwise a one-off entrance animation brands that address for the rest of the session.

Results on the synthetic worst case - a coherently panning video over 76% of the viewport - went from 10, 30 and 2 misplaced rows across three seeds to 0, 1 and 11. On a real captured session, re-emitted rows went from 1056 to 0.

Defect two: the one placement checks cannot see

Meanwhile the user kept saying the video area still overlapped, and my audit kept reporting zero misplaced rows. We were both right.

A media area's rows arrive over many frames. The video moves on between them. So the area ends up assembled from different instants - the scene visibly cuts part-way down - while every row sits at exactly the page address it belongs to. Positional accuracy cannot fix it, because the addresses were never wrong. The moment was.

You need a second measure entirely: for each animated page range, how many distinct source frames contributed. One is coherent. More is a tear. Adding that number to the audit was the first time the defect became visible as a number instead of as a complaint.

The fix follows directly: stop stitching those rows. Once a media area is wholly on screen in a single frame, that frame holds a coherent picture of it, so write the whole area from that one frame, with static rows riding along on both sides so the canvas can prove the placement before anything lands.

What I would tell my past self

Build ground truth that does not run through the thing you are testing. My audit and my engine shared a measurement for a while, so they agreed with each other while both were wrong.

Fixtures can lie by being too kind. The noise-video fixture passed. It felt like evidence. It was the absence of evidence.

When two failures share one symptom, the user is usually reporting the one your instrument cannot see. Three rounds of "still broken" against a clean audit should have told me the instrument was incomplete far sooner than it did.

The app is LongShot - free, no ads, no accounts, and no INTERNET permission at all, which for a tool that reads your screen felt like the only defensible design. Text tools are Latin-script only and you do the scrolling yourself; there is deliberately no accessibility service.