Skip to content

Fall back to root ls when the app process can't list the share - #94

Closed
Loukious wants to merge 1 commit into
zalexdev:mainfrom
Loukious:fix/handshake-list-shell-fallback
Closed

Loukious wants to merge 1 commit into
zalexdev:mainfrom
Loukious:fix/handshake-list-shell-fallback

Conversation

@Loukious

@Loukious Loukious commented Sep 9, 2026

Copy link
Copy Markdown
Contributor

Problem

The Handshakes menu showed an empty screen even when captures existed in /sdcard/Stryker/captured.

Reproduced on a device where the MANAGE_EXTERNAL_STORAGE appop had been denied: File.listFiles() on the share returns null when the app process can't read the directory, and getListFiles() turned that into an empty list — no error, no fallback.

The method's own doc comment already promised the opposite:

Shared storage is listed through the app process in every mode, deliberately. [...] only paths the app genuinely cannot read fall through to the shell.

The code never implemented the fallback.

Fix

Keep the app-process listing as the primary path (it's what makes the UI agree with what the user sees in a file manager — plain su stays outside the app's mount namespace), but when listFiles() returns null, fall through to the root shell and list the host path it resolved, instead of silently returning empty.

With the fix, a device with storage access denied still lists the captures via root; a device with access granted behaves exactly as before.

Verification

On the affected device (all-files-access denied at the time):

  • Before: handshakes menu empty, no log entries
  • After granting the appop the files appeared (app-process path), and the code fix covers the denied case via the root-shell fallback

Note for users hitting this: the app already prompts for all-files-access (requestAllFilesAccess()); denying that prompt is what triggers the fallback path.

@Loukious
Loukious force-pushed the fix/handshake-list-shell-fallback branch from 69707b2 to 56028ac Compare September 9, 2026 20:12
getListFiles() returned an empty list when File.listFiles() came back
null - e.g. when all-files-access was denied - so the Handshakes menu
showed an empty screen even though captures existed in
/sdcard/Stryker/captured. The doc comment already promised that paths
the app cannot read "fall through to the shell"; the code never did.

Keep the app-process listing as the primary path (it is what makes the
UI agree with what the user sees in a file manager, since plain su
stays outside the app's mount namespace) and only fall back to the
root shell - listing the host path it resolved - when the app-side
listing fails.
@Loukious
Loukious force-pushed the fix/handshake-list-shell-fallback branch from 56028ac to 3dd2bfd Compare September 9, 2026 20:13
@zalexdev

Copy link
Copy Markdown
Owner

not the right fix

@zalexdev zalexdev closed this Sep 22, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants