Real apps

Reviewing real Android apps against real reported bugs

We tested real open-source Android apps against bugs their own users reported in public and their own maintainers later fixed. For each bug we take the release that had it and the release that fixed it, run the same review on both, and publish the result whatever it is. If the review reports nothing on the fixed release, that only counts as evidence when the same run shows it actually reached the screen being tested.

We registered eleven bugs in advance. Two are verified: the review reproduced the bug on the build that carried it, and the same steps on the repaired build came back clean. Four were reviewed and the review could not prove the fix. Five are excluded from any success rate because our test equipment could not produce the bug. On three of those the review reached the screen and the fault never appeared; on the other two no review ran at all, one because its set-up never completed and one because the check that has to reproduce the bug first walked the whole route without it appearing. Two more were registered against a messaging app, never run, and have now been withdrawn; they are no longer listed and they are not counted anywhere on this page. The rolling results and the extra findings further down came from different pieces of work and do not change these numbers.

At a glance

Eleven bugs registered in advance across seven apps. The table shows where each one stands; every row links to its full record, including what each result does and does not show. Two are caught: in each of those the review reproduced the reported bug on the build that carried it and then took the same steps on the repaired build, which came back clean. The rest are not, and the reasons differ row by row, so the full records are where the reading has to happen.

AppThe bugWhere it standsDetail
AnkiDroidOpening a deck's options closed the app.CaughtFull record
AnkiDroidOpening a deck's options closed the app again, a few releases later, for a different reason.We did not prove this oneFull record
Tasks.orgOpening the app's own settings closed the app, when the place it saves backups was not available.Our rig could not produce itFull record
Tasks.orgAdding a tag or a location to a task left a blank white screen you could not get out of.Our rig could not produce itFull record
Nextcloud FilesTapping the three dots beside a file that had been changed in two places at once, and choosing to download the server's copy, closed the app.Our rig could not produce itFull record
Nextcloud FilesMoving from the media view back to all files left the sorting and view controls missing.We did not prove this oneFull record
ThunderbirdSetting up an account closed the app, when the network was returning nonsense answers.Our rig could not produce itFull record
ThunderbirdRenaming an account left the old initials showing on screen.We did not prove this oneFull record
Fossify CalendarOpening an event, or starting a new one, closed the app.CaughtFull record
Fossify NotesTyping in the search box closed the app, after swiping from one note to the next.Our rig could not produce itFull record
Fossify GalleryA photo you had rotated and saved opened as a blank screen.We did not prove this oneFull record

Separate from these eleven, the review reported four problems nobody asked it to look for, each checked against the app's own published source code before we listed it.

The full record, app by app

AnkiDroid

A flashcard app for studying.

No sign-in. It runs on a deck we put there ourselves.

Caught

Opening a deck's options closed the app.

Reported upstream
Reported by a user
What the project did
The project found the settings were being read before they existed, and fixed it.
What our review did
Our review found it. On the build that had the bug it pressed and held a deck, opened its options, and the app died there, two actions in. Our crash detector recorded the crash, and it is the same crash the user reported.
On the build that fixed it
Clean, on the same route. On the repaired build the review took the same two steps, reached deck options, and nothing crashed. A second pass went back over the recorded run, reached that screen again, and filed the crash as repaired. All six of the checks we set in advance came back true.

What we owe you about this one. Start with what we published before. This page carried this same bug as a miss, because the earlier run reproduced the crash and then never opened the same screen on the repaired build. That earlier account is still true about that run, and the independent verifier's words for it were that the run “does not independently demonstrate the fix” and was “a transparent crawler miss, not verified fix evidence”, in docs/ANKIDROID-ANK1-FINAL-RERUN-VERIFICATION-2026-08-31.md. What you see above is a later run of the same bug on the same two builds, registered in advance again, that did both halves. It took seven attempts to get there, and the six before it are listed in our own record as unresolved rather than as results, each one ending in a fault of ours: a comparison that drifted, a fixture that refused to build, a screen our review could not reach, and a control it could see but not press. One more thing you should weigh: these builds are early test releases the project publishes before a finished version, not the stable ones most people install.

We did not prove this one

Opening a deck's options closed the app again, a few releases later, for a different reason.

What the project did
The project traced it to a setting that could be empty when the screen was built, and fixed it.
What our review did
Our review found it, but by a different route than planned. Instead of pressing and holding a deck, it opened deck options from the menu inside the reviewing screen. The app crashed there and our crash detector recorded it. It is the same fault on the same screen, reached a different way.
On the build that fixed it
Nothing to show. On the repaired build the review never reached deck options and stopped making progress, so the comparison could not be made at all. No crash, and nothing attempted to cause one.

What we owe you about this one. Also a miss, and this one carries a second thing we owe you. Our review reached the broken screen by a different route than the one we had committed to in advance: it came through the menu inside the reviewing screen rather than by pressing and holding a deck. It is the same fault and the same screen, but it is a weaker claim than the one we set out to make, and we would rather say so than quietly accept the result. As with the other one, the repaired build was never exercised, so there is no fix proof; and the same fault in our scoring applies, reading the filed label rather than the detector's receipt and so reporting that nothing was found. These four builds are early test releases the project publishes before a finished version, not the stable ones most people install.

On AnkiDroid 2.16alpha54, the crawler opened Deck options from the Reviewer overflow menu and captured the same Kotlin-nullability crash documented in upstream issue #10687. On 2.16alpha55, it never exercised Deck options and the regression comparison became untestable, so this run does not independently demonstrate the fix. The final-rerun chain is a transparent crawler miss, not verified fix evidence.

Independent verifier, quoted in full: docs/ANKIDROID-ANK2-FINAL-RERUN-VERIFICATION-2026-08-31.md, the verifier's report, “Publication-safe result”

Tasks.org

A to-do and reminder app.

No sign-in. It runs on tasks we add ourselves.

Our rig could not produce it

Opening the app's own settings closed the app, when the place it saves backups was not available.

What the project did
The project made it fall back to internal storage instead of failing.
What our review did
The review did reach it. On the release that had the bug it opened the app's own settings screen, stayed on that screen, and nothing crashed or closed.
On the build that fixed it
Nothing to compare against. The bug never appeared on the release that is supposed to have it, so there is no before-and-after here.

What we owe you about this one. Our equipment could not produce this one, so we exclude it from any success rate. Here is what that does and does not show. It does show the review reached the right control, and that the fault did not appear on our rig. It does not show the release is unaffected: the bug needs the app's external storage to be unavailable, and we did not force that condition or measure it independently, so we never put the app into the state the bug requires. Earlier attempts on this chain either failed on our own infrastructure or stopped before reaching the target screen; those are counted separately, and none of them is evidence that the bug does or does not exist.

Our rig could not produce it

Adding a tag or a location to a task left a blank white screen you could not get out of.

What the project did
The project restored the half-finished edit instead of losing it.
What our review did
Our rig could not produce it
On the build that fixed it
Our rig could not produce it

What we owe you about this one. Our equipment could not produce the bug, so this chain proves nothing either way. The review walked the whole path on the build that is supposed to be broken and the fault never appeared, which means the problem is with our test rig rather than with the app or the review. We exclude it from any hit rate rather than scoring it as a pass or a failure. The two findings further down came from the same app; they are separate observations and they do not rescue this chain.

Nextcloud Files

A file app for a server you run yourself.

Signs in with a real account on a real server.

Our rig could not produce it

Tapping the three dots beside a file that had been changed in two places at once, and choosing to download the server's copy, closed the app.

Reported upstream
Reported by a user
What the project did
The project moved the error-and-finish step onto the main screen thread, which is what was crashing.
What our review did
The review got to the right place. It found the file that had been changed in two places at once, opened it, and reached the screen that asks you to resolve the clash. That screen then offered a different set of choices than the one this bug is about, so the specific action we needed was not there to take.
On the build that fixed it
Nothing to compare. The action that triggers this crash was never available on our set-up, so the crash could not happen and its absence means nothing.

What we owe you about this one. Our equipment could not produce this one, so we exclude it from any success rate. The review reached the right screen, which is worth saying, but the version and server we tested against offer different buttons there than the ones the report describes. We never took the action that causes the crash, so nothing here shows the release is unaffected or that the repair works. An earlier attempt failed before it could even sign in, for reasons on our side; that attempt is counted separately and is not evidence either way.

Exact row-owned Sync reached the production conflict UI, but that UI offered New file / Already existing file instead of the sealed server-version action. No sealed resolution was delivered and no causal crash was classifiable. Rig/build incompatibility only.

Independent verifier, quoted in full: docs/ROUND-23-TERMINAL-LIVE-SEQUENCE-REVIEW-2026-09-03.md, the verifier's report, “Publication-authoritative row replacements”
We did not prove this one

Moving from the media view back to all files left the sorting and view controls missing.

Reported upstream
Reported by a user
What the project did
The project restored the controls on that transition.
What our review did
The review ran on both builds and both runs finished properly. Neither run made the journey this bug is about. On the build with the fault it reached an ordinary file list and used the sorting and view controls there, but it never went to the media view first and came back, which is the step that breaks them. On the repaired build it stopped after three actions and never began that part of the walk at all.
On the build that fixed it
Nothing to compare. Neither run reached the screen the bug is about, so there is no before and after here, and nothing on this chain shows the repair works.

What we owe you about this one. We count this as a miss and we are claiming nothing about the repair. Both runs were valid and both used the same agreed plan, so the comparison itself was set up correctly. The review simply did not go where the check was waiting. Two things need saying plainly. The first is about a label: our own scoring came out of this run marked untestable, and that label must not be read as the result. We already hold a recording from this same equipment showing the affected build reaching that screen with the controls missing, so the equipment can produce this bug. What went wrong is that this run did not go there. The second is about the check itself: on the build with the fault, the part of the review that reads the screen images finished none of its work. It made twelve attempts, completed none, and four of them timed out. So even if the walk had arrived, that check had nothing to report. This was the last run planned for this chain, which makes the miss final rather than pending. It does not turn it into a better result.

NC-2 | Nextcloud Files | RERUN_REQUIRED | final valid, mission-symmetric pair missed the sealed Media -> All Files route and baseline completed zero eligible vision inputs | publish as terminal honest miss; no fix credit; generated untestable is non-authoritative

Independent verifier, quoted in full: docs/NEXTCLOUD-NC2-FINAL-BOUNDARY-PAIR-REVIEW-2026-09-01.md, the verifier's report, “FINAL TABLE LINE”

Thunderbird

An email app.

Signs in with a saved mail account.

Our rig could not produce it

Setting up an account closed the app, when the network was returning nonsense answers.

What the project did
The project fixed the crash during account setup.
What our review did
No review ran. Setting this one up needs a deliberately broken network, and the test phone would not tell us the setting we needed to point it at our broken one. The set-up step stopped rather than guessing, so neither build was ever opened.
On the build that fixed it
Nothing to compare. Because the set-up never completed, no run happened on either build.

What we owe you about this one. Our equipment could not produce the conditions this bug needs, so we exclude it from any success rate. This says nothing about the app. It does not mean the reported crash is absent, and it does not mean the repair works. We never got far enough to look. The set-up failing safely rather than running anyway is the behaviour we want, but it leaves us with no result.

API-34 guest route authority could not be established, so the manifestation gate failed closed and no crawls ran. Rig infeasibility only; do not imply the reported crash is absent or fixed.

Independent verifier, quoted in full: docs/ROUND-23-TERMINAL-LIVE-SEQUENCE-REVIEW-2026-09-03.md, the verifier's report, “Publication-authoritative row replacements”
We did not prove this one

Renaming an account left the old initials showing on screen.

Reported upstream
Reported by a user
What the project did
The project made the initials follow the name you set.
What our review did
We checked by hand first that the bug is really there on the older build and really gone on the newer one, and both checks came out right. That is what makes this chain count. Then the review ran on both builds and finished both times, but neither run completed the step that renames an account, so the screen this bug appears on was never reached.
On the build that fixed it
Nothing to compare. The review never reached the screen, so there is no before and after, and nothing here shows the repair works.

What we owe you about this one. We count this as a miss, and unlike the two rows above it does count against us: we confirmed by hand that the bug was present on one build and gone on the next, so this chain was genuinely testable. The review still did not find it. Of the things it did report, none was the bug we were looking for. Our combined score for this app was never produced at all, because the other Thunderbird chain failed its set-up and the two are scored together. That is an honest gap in our tooling rather than a result, and it does not earn this chain any credit either way.

Both direct manifestations were correct, but the valid corrected crawl pair completed 0 fixed / 0 still / 3 untestable and persisted no typed T2 mismatch. The coupled campaign score was honestly uninvoked because T1 prevented the four-crawl census. Do not grant detection or fix credit.

Independent verifier, quoted in full: docs/ROUND-23-TERMINAL-LIVE-SEQUENCE-REVIEW-2026-09-03.md, the verifier's report, “Publication-authoritative row replacements”

Fossify Calendar

A calendar app.

No sign-in. It runs on a calendar we set up ourselves.

Caught

Opening an event, or starting a new one, closed the app.

What the project did
The project stopped the event editor reading a list that could be empty, and named the fix in its release notes.
What our review did
Our review found it. On the build that had the bug it pressed and held a day, chose Event from what came up, and the app died in the editor, two actions in. Our crash detector recorded the crash, and it is the same one the report describes.
On the build that fixed it
Clean, on the same route. On the repaired build the review opened the editor the same way and nothing crashed. A second pass went back over the recorded run, reached the editor again, and filed the crash as repaired. All six of the checks we set in advance came back true.

What we owe you about this one. Three things we owe you here, none of which we think changes the result. The first is that we widened what counted before the run that sealed it: our plan named the round add button as the way into the editor, and we added pressing and holding a day as an equally acceptable way in. Both were written down before the sealing run, not after it, and the crash is the same crash on the same screen either way. The second is that the run on the repaired build later ran into timeouts from the service our review uses to decide what to do next. Those came after the step this bug is about, so the comparison itself stands, but the run was not clean from end to end and we would rather say so. The third is the attempts behind it: the first run never reached the editor at all and we recorded it as a miss, and a later one was cut short by the same kind of timeout, which is why we now check that service before a run starts.

Fossify Notes

A notes app.

No sign-in. It runs on notes we put there ourselves.

Our rig could not produce it

Typing in the search box closed the app, after swiping from one note to the next.

Reported upstream
Reported by a user
What the project did
The project cleared the search state when the page changes, and named the fix in its release notes.
What our review did
No review ran on this one, and this is why. Before a review is allowed to start, a scripted check has to reproduce the bug on the build that carries it. That check put two long notes in place, searched inside one of them, used the arrows, swiped to the next note, opened search again and typed the same word, which is the whole registered route. The app stayed up, no app exception was recorded, and the screen at the end still belonged to the app. Because the bug never appeared, no review of either build was authorised.
On the build that fixed it
Nothing to compare against. The bug never appeared on the build that is supposed to have it, so there is no before and after here, and no review was ever started on the repaired build.

What we owe you about this one. Our equipment could not produce this one, so we exclude it from any success rate. What this does show is that the route was walked faithfully: every character the check typed was read back off the screen before the next step, and the notes it seeded were verified character for character first. What it does not show is that the release is unaffected. The person who reported it was on a different device and a different Android version, and we did not reproduce their conditions; we only ran the route they described. Getting even that far took seven numbered attempts. The first six were defeated by faults of ours rather than by anything the app did: a text field we misread as already filled, a long note that only partly arrived, a screen we captured before it had drawn, and a search bar that closed itself when we swiped. The seventh ran the whole route faithfully and completely and the crash did not appear, and that seventh attempt is what this result rests on. If we want to test this bug another way, that is a new plan written in advance, not a rerun of this one.

Fossify Gallery

A photo gallery app.

No sign-in. It runs on a photo we put there ourselves.

We did not prove this one

A photo you had rotated and saved opened as a blank screen.

Reported upstream
Reported by a user
What the project did
The project made the app fall back to a second image loader when the edited file fails to draw, and named the fix in its release notes.
What our review did
Nothing to show from the review. On both builds it tapped the photo and tapped Edit, and then Android itself asked which app should do the editing. Our review has no way through that question, so all four runs stopped there, four actions in, without ever opening the editor.
On the build that fixed it
Nothing to compare. Neither build was taken past that point, so there is no before and after here, and nothing in these runs says anything about the repair.

What we owe you about this one. We count this as a miss and the cause is ours, not the app's: our review cannot get through the chooser Android puts up when more than one app can edit a photo. It stopped at exactly the same place on all four runs, including both runs of the control described below, which is what tells us this is our limitation rather than something about either build. The bug itself is real on our equipment, and we can show that separately: away from the review, a scripted reproduction recipe drove the reported steps on the affected build and the rotated photo opened as a black screen with the file name above it, while the same file's thumbnail drew correctly in the list a moment earlier. An independent reviewer, not the person who built the steps and not the person who ran them, looked at those pictures and recorded that judgement, and the same run was repeated against an identical copy of the same build to check that we had not repaired anything by accident. None of that is detection credit. Our review did not find this bug, and that is the result we are publishing.

Rolling results on apps we registered nothing for

These are different from the chains above and they prove something much smaller. Each row is one release of an app and the release that came next, reviewed the same way. Nobody registered a bug for these apps in advance, so there is no right answer to compare our review against: no catch, no miss, and no success rate. What a row shows is how much of an app the review got through, what it reported, and whether it could go back to the same places on the newer release. The things it reported are unchecked: unlike the four findings further down, nobody has read the app's source to confirm any of them, and some of them will be wrong. Across all eight reviews nothing was shown to be fixed, and every run stopped before finishing its plan.

Eight reviews were planned across four apps, and all eight have now run. Four pairs closed. Loop Habit Tracker got there on its fourth attempt: its first three stopped at start-up before reviewing anything, and they are counted as our failures rather than results. One attempt on another app was killed by the machine it ran on and is counted as an outside failure rather than a result. Across the eight reviews that ran, none showed a problem to be fixed.

AppFirst reviewSecond reviewWent back to check
AntennaPod1 of 6 planned tasks, 3 reported4 of 7 planned tasks, 6 reportedSee the record
Feeder1 of 6 planned tasks, 19 reported3 of 7 planned tasks, 12 reportedSee the record
Omni Notes3 of 5 planned tasks, 12 reported3 of 7 planned tasks, 19 reportedSee the record
Loop Habit Tracker4 of 7 planned tasks, 15 reported4 of 7 planned tasks, 9 reportedSee the record
Both releases reviewed

AntennaPod

A podcast player.

How much of the app each review got through
First review: 1 of 6 planned tasks. Second review: 4 of 7 planned tasks.
What each review reported
First review: 3 things, 1 from the checks and 2 from reading the screen. Second review: 6 things, 3 from the checks and 3 from reading the screen. None of them has been confirmed.
Why each review stopped
First review: it ran out of its budget with most of its plan unstarted. Second review: it ran out of its budget with part of its plan unstarted.
Going back over the first review's findings
Of the earlier findings it went back to check, two were still there on the newer release and two could not be checked at all. Nothing was shown to be fixed.

What this does and does not show. Both releases were reviewed and the second review covered more of the app than the first. That is the whole claim. Nobody registered a bug for this app in advance, so there is nothing here to catch or miss, and the second review's block verdict is our own tool's opinion about what it saw rather than a confirmed defect in the release.

Both releases reviewed

Feeder

A feed reader.

How much of the app each review got through
First review: 1 of 6 planned tasks. Second review: 3 of 7 planned tasks.
What each review reported
First review: 19 things, 3 from the checks and 16 from reading the screen. Second review: 12 things, 3 from the checks and 9 from reading the screen. None of them has been confirmed.
Why each review stopped
First review: it ran out of its budget with most of its plan unstarted. Second review: it ran out of its budget with most of its plan unstarted.
Going back over the first review's findings
Of the twenty earlier items it went back to check, nineteen could not be checked at all and one was still there. Nothing was shown to be fixed.

What this does and does not show. A first attempt at this pair was killed by the machine it was running on, not by anything in the app or the review, and is recorded as an outside failure rather than a result. The pair was then run again from scratch. The re-check number above is the one that matters: on nineteen of twenty items the second review could not get back to what the first review had seen, so almost nothing here is a before and after.

Both releases reviewed

Omni Notes

A note-taking app.

How much of the app each review got through
First review: 3 of 5 planned tasks. Second review: 3 of 7 planned tasks.
What each review reported
First review: 12 things, 4 from the checks and 8 from reading the screen. Second review: 19 things, 4 from the checks and 15 from reading the screen. None of them has been confirmed.
Why each review stopped
First review: it could not prove it had recorded everything it did, so it stopped rather than claim the walk. Second review: the same unproved record of its own actions.
Going back over the first review's findings
Of the fifteen earlier items it went back to check, none could be checked at all. Nothing was shown to be fixed and nothing was shown to be still there.

What this does and does not show. This is the pair where coverage went down rather than up: the second review completed the same number of tasks against a longer plan. Both runs also ended by refusing to vouch for their own record of what they had done, which is the behaviour we want and is still a run that proved less than it set out to.

Both releases reviewed

Loop Habit Tracker

A habit tracker.

How much of the app each review got through
First review: 4 of 7 planned tasks. Second review: 4 of 7 planned tasks.
What each review reported
First review: 15 things, 3 from the checks and 12 from reading the screen. Second review: 9 things, 3 from the checks and 6 from reading the screen. None of them has been confirmed.
Why each review stopped
First review: it could not prove it had recorded everything it did, so it stopped rather than claim the walk. Second review: the same unproved record of its own actions.
Going back over the first review's findings
Of the nineteen earlier items it went back to check, none could be checked at all. Nothing was shown to be fixed and nothing was shown to be still there.

What this does and does not show. Three earlier attempts stopped two actions in, before the review had covered anything. The cause was on our side: an Android system notice about full-screen viewing covered the app when it first opened, and the review could not get past it. The review now recognises that notice and dismisses it in one step, and on the fourth attempt both releases were reviewed. Each review got through four of its seven planned tasks and ended inconclusive. Nobody registered a bug for this app in advance, so there is nothing here to catch or miss.

Two registered bugs we withdrew

These were registered in advance against a messaging app and never run. We have taken them off the table above rather than leave rows that would only ever have said we had not started, and they are counted nowhere on this page. Removing rows is the cheapest way to make a scoreboard look better, so here is exactly what was removed.

  • Element: The button for inviting someone to a room did nothing. Registered in advance, never run, withdrawn before any review. We are not carrying a row that would only ever have said we had not started.
  • Element: Tapping the round add button twice quickly closed the whole app. Registered in advance, never run, withdrawn before any review, for the same reason.

Other problems the review reported

These are separate from the bugs above. The review reported them without being asked to look for them, and we checked each one against the app's published source code before listing it.

There are four findings here: two from the to-do app and two from the file app. None is one of the bugs we registered in advance, and none of them changes the result of any chain above. The flashcard app produced three candidates and an independent check rejected all three. One was an unlabelled button the project had already reported and was already fixing. One was a menu control below the recommended size, which is a real problem but an example of a type of problem already reported. One was an overlap warning that turned out to be our own detector misreading a screen that layers deliberately. We did not report any of them first, so we do not list them here.

Buttons a screen reader cannot name

Several controls you can tap have nothing a screen reader can announce. Someone using one hears an unlabelled button and has to guess what it does.

How we checked. The review reported it, and we then read the app's own published source at the exact versions we tested and found reachable controls with no label. Android's own guidance says a control you can act on needs one.

What that does not mean. Three things this is not. It is not a release regression: it is present in both versions we looked at, so it is long-standing rather than newly broken. What we retain is the family of unlabelled controls, not a claim about one exact button - mapping the finding onto a specific menu control is our reading of the source and the screen, not something the run proves by itself. And on prior art we can only say this: no matching public Tasks.org issue was found in the searches we recorded, as of 30 August 2026. That is a statement about our search, not a claim that no such issue exists.

A menu control below the minimum touch size

The 'more options' control in the toolbar is 40 by 48 units. The recommended minimum for something you tap is 48 by 48, so it is easier to miss than it should be.

How we checked. Measured in the run at 40 by 48, against a recommended minimum of 48 by 48, and then traced to the published source at the versions we tested, which sets no larger minimum and adds nothing to widen the tappable area.

What that does not mean. Also not a release regression, and not really the app's own doing: the control comes from a shared Android component the app builds on rather than from sizing the app chose. We count it as real and we are saying where it comes from. On prior art, the same limit applies: no matching public Tasks.org issue was found in the searches we recorded, as of 30 August 2026, which is a statement about our search rather than about what exists.

Sort controls smaller than the recommended tap size

The controls that switch the file list between A to Z and Z to A are smaller than the recommended minimum for something you tap, so they are easier to miss than they should be.

How we checked. The review measured them in the newer of the two releases we tested and found them under the recommended minimum. We then read the app's own published source at both exact releases and found the same controls built the same way: the layout and the code that makes them clickable are identical between the two.

What that does not mean. Three things this is not. It is not the bug we registered for this app, which is about controls going missing rather than being small. It is not a release regression: the source is identical in both releases we tested, so this is long-standing rather than newly broken. And it does not rescue the registered chain, which we still count as a miss. On prior art we can only say that no matching public Nextcloud Android issue was found in the exact-candidate searches we recorded, as of 1 September 2026. That is a statement about our search, not a claim that no such issue exists.

The add button covers a file's share control

On the last row of the file list, the round add button in the corner sits partly over that row's share control, so part of the control is hidden behind it.

How we checked. The review reported it on the newer of the two releases we tested, and the screenshot it captured shows the add button overlapping the share icon on the last row. We then read the published source at both exact releases: the add button is placed in the bottom corner over a list that runs the full height, with nothing added to keep the last row clear of it, and those layout files are identical between the two releases.

What that does not mean. Several limits, and one of them matters more than the rest. We only observed this on the newer release. The identical source tells us the same layout would produce it on the older one, but we did not see it there ourselves and we are not claiming we did. Beyond that: it is not the bug we registered for this app, it is not a release regression, and it does not rescue the registered chain, which we still count as a miss. On prior art, no matching public issue was found in the scoped searches we recorded, as of 1 September 2026. There are older reports about a pop-up message covering this same add button, and about the button appearing on a sharing screen, but those are different problems from this one.

The full working, including the runs that failed and why, is in the evidence pages.